Summary

  • HTTP/1.1's January 1997 RFC 2068 documented Accept-Language: a browser could rank acceptable languages with quality values, leaving the server to choose a suitable response.
  • A server choosing by that request field could send Vary: Accept-Language. The cache then had to compare language preferences before reusing a stored response for another visitor.

The browser arrived at the server with a menu order in its pocket. In RFC 2068, published in January 1997, the Accept-Language example prefers Danish, then British English, then other English. The little q values rank acceptable choices. No one has to fetch a separate language menu before the first page appears. The request carries the preference along with the address.

That convenience creates two decisions, not one. The server decides which edition to return. Then a cache that stores the result must decide whether the same response can serve the next visitor. Both people might request /news; one browser might have asked for Danish and the other for French. A cache keyed only by the URL sees the same shelf label. It needs to know what else decided the contents of the shelf.

HTTP supplied the extra label: Vary. The current HTTP Semantics specification says a response with Vary: accept-language identifies the request field that helped select its representation. The HTTP Caching specification gives the cache its rule: a stored response carrying that field must not be reused without revalidation unless the nominated request field matches the original request. The cache is allowed to remember the Danish edition. It must also remember why that edition was chosen.

The missing-label failure is pleasingly ordinary. RFC 9111 notes that if a server forgets Vary on its default response, a cache can keep choosing that default for later requests even when a more suitable variant exists. The wrong-language page needs no exotic attack. It needs one shelf with no language marker and an efficient clerk following the label it was given.

The response may describe the edition it actually carries with Content-Language, a separate field defined in RFC 9110. The request says what the browser prefers; the response says what audience the content addresses; Vary tells caches which request distinction mattered. Those are three pieces of one transaction. Treating them as one vague “language setting” makes it easy to lose the reader between server and cache.

There is still a person behind the browser. The W3C's language-negotiation guidance gives a memorable case: someone using a borrowed browser can inherit its configured language and receive a poor match. It recommends visible controls so a reader can choose another edition directly. A preference header is a useful opening guess; a language switch is the reader's reply.

The 1997 RFC already noticed another cost: sending a full list of linguistic preferences with every request can reveal more than a visitor intended. RFC 9110 keeps user control over that list in the protocol. HTTP's dinner service works when each part does its job: the browser expresses a preference, the server chooses, the cache keeps the seating chart, and the reader can ask for a different plate.