- From: Nicolas Grekas <nicolas.grekas@gmail.com>
- Date: Mon, 30 Jan 2023 13:45:08 +0100
- To: ietf-http-wg@w3.org
- Message-ID: <CAOWwgpmT2PaXc_=N+Hnu-ZOXFFmczxKuoy9P_K4V7nmvRT_B1g@mail.gmail.com>
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
Received on Monday, 30 January 2023 18:34:09 UTC