Vary and Availability Hints (again)

(with my just-me hat on)

A long while back we recognised that the Vary header in HTTP is not great. 

Caches -- especially those that store more than one variant for a given URL -- have trouble deciding what to do with Varying responses, because while they might have a view of the client's preferences (thanks to q values), they don't have a complete view of what's on the server, or how the server would behave if presented with the request. As a result, they have to choose between lost efficiency and serving an incorrect response. Their behaviour is also hard for servers to predict.

Caches also don't do a lot to normalise request headers to figure out how to consider them equivalent, as seen in the cache tests:
  https://cache-tests.fyi/?id=vary-normalise-combine&id=vary-normalise-lang-order&id=vary-normalise-lang-case&id=vary-normalise-lang-space&id=vary-normalise-lang-select&id=vary-normalise-space#vary

Finally, caches that store more than one variant for a given URL have to look up state for every stored response to serve a request correctly according to the specification. This creates an unacceptable performance hit for many, leading to variance in behaviour. 

Over the years, we've tried to address some or all of these problems:

* In 2015, we adopted the Key spec - <https://datatracker.ietf.org/doc/draft-ietf-httpbis-key/>. This created a little language that servers could put into a response header to describe how caches could create a secondary cache key for that resource. 

We worked on Key for a while, but IIRC there wasn't strong interest in implementation, and concerns grew about the complexity that creating and maintaining this header put on servers -- as well as how much of a potential "foot gun" it might be.

* In 2018, we adopted the Variants spec - <https://datatracker.ietf.org/doc/draft-ietf-httpbis-variants/>. Variants moved the responsibility for describing the algorithm for creating a cache key to individual specifications that use content negotiation, leaving servers to just annotate what choices they've made. This has the advantage of less server complexity (and risk), but does raise the bar for introducing new content negotiation features (since caches will need to be updated for each).

Variants saw more interest than Key (although Key still has its proponents!), but there again wasn't much immediate implementation interest, and the headers were still not very intuitive to set for content owners / server operators.

* In 2023, I started work in Availability Hints - <https://datatracker.ietf.org/doc/draft-nottingham-http-availability-hints/>. Availability Hints are conceptually similar to Variants, but "spelled differently" in the headers -- each content negotiation mechanism just needs to convey the set of response representations a server has available in that dimension of negotiation, using a header it nominates. 

This turns out to be much more intuitive, and also is potentially useful for things other than caches. For example, Chrome has been looking at using Availability Hints to reduce the risk of Accept-Language being used for fingerprinting; see <https://github.com/explainers-by-googlers/reduce-accept-language>.

Availability Hints is an incremental improvement: caches will now have a much better view of what's on the server, and some information about the server's actions. It provides a shortcut to looking at every stored response, and it also has the promise of unobtrusive implementation on servers that do content negotiation (e.g., from filename extensions on the filesystem). 

I (again, personally) think this is an important problem to work on in HTTP. I haven't been pushing for adoption very strongly because I'd prefer to see solid plans to implement (this being our third swing at this), but acknowledge that this is a bit chicken-and-egg; it's hard to get cache engineering teams to commit to implementation until there's content that uses the mechanism, and it's hard to get content engines to commit until there are caches that support it.

I'd be very keen to hear what people think, and would like to ask for a slot in Madrid to talk about it again if there's time.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Saturday, 28 June 2025 11:32:51 UTC