There have been recent reports of cached language contamination for Browse Happy. Locales that don’t necessary match the visitor’s preference are being presented to some visitors (depends on what language version of the site happened to warm the cache and what the visitor’s preferred language is).

That first set of reports indicated Chinese was served, despite being en_US in California. Later, others reported incorrectly seeing Hebrew. I checked and saw Hebrew myself, then shortly thereafter saw English. Currently I see Portuguese.

This appears to be a page-cache keying issue. The site is serving cached HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. (X-CACHE: HIT) and only advertises Vary: Accept-Encoding, which is not sufficient for language negotiation. The application chooses locale from the Accept-Language request headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. (unless an explicit ?locale= is provided). If the cache key for / does not vary by language, whichever language variant warms that cache entry can be served to subsequent visitors until expiry or purge.

Additional testing shows /?locale=he is also cached (X-CACHE: HIT), which suggests query-string variants are cached separately. So it seems the primary gap is handling of Accept-Language for plain / requests.

I haven’t seen reports of this until now, and the site hasn’t changed in years (other than coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP). Not sure if caching was changed/implemented somewhat recently, or if just no one has reported it (though I had never seen it myself but have certainly done so a few times in the last couple days).

Solution considerations:

A. Add Accept-Language to the cache key for HTML (or otherwise ensure cached responses vary by it). The raw Accept-Language is noisy (en-US,en;q=0.9, en-GB,en;q=0.8, etc.), so keying on the full header will create many cache variants, though that would be necessary for correctness. Normalization might seem attractive (e.g. bucketing by the first language tag), but preference is expressed with q values, so “first tag in header order” is not always the same as the app’s choice after sorting by q. Implementing this as Vary: Accept-Encoding, Accept-Language on HTML (if the cache honors it) is equivalent in intent to including the header in the cache key. Even with increased cache variants, visitors should at least get a response consistent with their negotiated language.

B. The site could (but currently doesn’t) set a cookie which would set the language (e.g. bh_locale=en_US) and could be used as part of the cache key, but that requires allowing first requests to pass through to the site for that determination. This would result in one uncached resolution per new visitor, then cache hits keyed by cookie.

C. Or, caching could be disabled. The site only has its root page, which though it loads WP, does not make any additional queries for content. Static assets could still be cached.

Testing:

The site should serve different versions of the front page (check the content) based on the Accept-Language header for each of these (English, Hebrew, and Chinese, respectively). (You can compare obvious differences as seen when using ?locale= in query to get the same language, e.g. https://browsehappy.com/?locale=he-IL.)

curl -H "Accept-Language: en-US" https://browsehappy.com
curl -H "Accept-Language: he-IL" https://browsehappy.com
curl -H "Accept-Language: zh-CH" https://browsehappy.com

#prio1