Idea for a new header to aggregate Vary headers' values

[Nicolas Grekas <[e-mail]>]

Hi all,

I'm new to this mailing list and I don't know if I'm following the correct
process. Please let me know if I should do things differently.

Last September I met Darrel Miller at a conference and we chatted about the
Vary header and its shortcomings. One of them is that the variety of values
to vary-by can become huge. A simple "Vary: User-Agent" can yield a huge
amount of cached resources.

I've friends who solve this by doing a preflight request to some
header-normalizer service they have in their stack: a request comes in,
Varnish goes to that service, the User-Agent comes back with some
normalized values, and then varnish can hit its cache storage with a much
better cardinality.

This is no simple setup and I'm wondering if a response header, possibly
combined with 103 Early Hints couldn't make this much cheaper.

The response header I'm proposing would contain the normalized value of
every header to vary-by. I don't know how to encode that exactly. It could
be e.g.: "Vary-Values: User-Agent: firefox, Accept-Encoding: identity, etc."
We could also imagine a header to provide the normalized URL back,
Vary-Url: http://the-normalized-url.
(We could imagine that "Vary-Values" completely replaces "Vary" when both
are found - but I've not thought much about this aspect.)

These normalized values could be useful for reverse-proxies, to optimize
their storage requirements + their hit/miss ratio.

103 Early Hints could also be used by reverse-proxies to abort a request to
the backend app when that app sends a Vary-Values.

Does it make sense? Has this been considered before?
Please let me know if it's not clear enough of course.

Regards,
Nicolas