How does the HTTP Accept-Language header work, and why is the Accept-Charset header effectively obsolete?

## Accept-Language Natural language is a negotiable axis just like media type. The client sends the languages it can read: ``` Accept-Language: en-GB, en, fr ``` Each entry is a **language tag** as defined by BCP 47 — a hyphen-separated sequence of subtags: primary language (`en`), optional script (`Hant`), optional region (`GB`), optional variants (`oxendict`). Tags are case-insensitive, though the convention is lowercase language, Titlecase script, UPPERCASE region: `zh-Hant-TW`. The wildcard `*` is allowed and means "any language", which is what a client says when it will take whatever you have. ## Matching: filtering vs lookup RFC 4647 defines two ways to match a requested tag against available tags: **Basic filtering** — a range matches a tag if the tag equals the range or begins with the range followed by a hyphen. So the range `en` matches `en`, `en-GB`, `en-US`, but *not* `eng` (subtag boundaries are respected, it is not raw prefix matching). **Lookup** — used when you must return exactly one result. Truncate the requested tag from the right, one subtag at a time, until an available tag matches: `en-GB-oxendict` → `en-GB-oxendict`? → `en-GB`? → `en`? → default. Note that single-character subtags are skipped during truncation, and that lookup never widens sideways — it will not turn `en-GB` into `en-US` unless you also stock `en`. The practical consequence: **stock the base language.** If your catalogue has `en-US` and `pt-BR` only, a client asking for `en-GB` or `pt-PT` gets nothing by lookup and falls to your default. Publishing generic `en` and `pt` entries, or explicitly mapping regional variants, avoids the surprise of a UK user seeing your fallback language. ## Reporting the choice The response should say which language it actually is: ``` Content-Language: en-GB Vary: Accept-Language ``` `Content-Language` describes the intended audience of the representation and may list several tags for genuinely multilingual documents. `Vary: Accept-Language` is required for any shared cache to be correct — without it, the first visitor's language is served to everyone. Because Accept-Language values are long and highly variable, edge caches normally **normalise** the header down to the small set of languages actually supported before it enters the cache key. ## Where the language preference should really come from A seasoned answer notes that `Accept-Language` is a *default*, not a decision. It reflects OS/browser configuration, which is often wrong (a shared machine, a corporate image, a traveller). Production systems therefore treat it as the first-visit hint and then persist an explicit user choice — in a cookie, a profile setting, or a URL/locale path segment — and keep the URL distinct per language where SEO matters. Serving different languages from one URL is legal but makes indexing and link sharing harder. It is also a fingerprinting surface: the full ordered list of languages is unusually identifying, which is why privacy-hardened browsers trim it. ## Accept-Charset: why it is gone `Accept-Charset` was the request-side control for character encoding — e.g. `Accept-Charset: utf-8, iso-8859-1`. It was **deprecated in RFC 7231** and is not sent by any current browser. The reasons: - **UTF-8 won.** Essentially all modern content is UTF-8; negotiating an encoding solves a problem nobody has any more. - **Poor value, real cost.** It added per-request bytes and fingerprinting entropy for near-zero benefit. - **Wrong layer.** Encoding is a property of the representation and travels perfectly well as a media-type parameter on the response: `Content-Type: text/html;charset=utf-8`. For `application/json`, the encoding is fixed as UTF-8 by the JSON media type itself, so a `charset` parameter there is redundant (and harmless but noisy). A server that still branches on `Accept-Charset` is coding for a client that does not exist. The correct modern behaviour is: always emit UTF-8, always label text media types with `charset=utf-8`, and ignore `Accept-Charset` entirely. Note the name collision to avoid in interviews: `Accept-Charset` is about character encoding, `Accept-Encoding` is about compression — unrelated concerns despite the similar names.