Re: No-Vary-Search

Hi Jeremy,

> On 19 Mar 2024, at 11:44, Jeremy Roman <jbroman@chromium.org> wrote:
> 
> Unfortunately it is not possible for me to join personally (time zones and personal complications). We might be able to brief a Chrome team member who is attending if there is interest (depending when this is), though as you point out it would necessarily be a fairly brief overview on short notice (so it might not be possible).

It doesn't look likely that we'll have time for additional presentations. I'd suggest continuing the discussion on the list.

Just for some context -- we found this kind of capability useful when I was at Yahoo! way back in 2010:
  https://www.mnot.net/talks/pdf/Stupid_Web_Caching_Tricks.pdf#page=36

Cloudflare supports configuration to ignore the whole query string, as well as specific arguments in it:
  https://developers.cloudflare.com/cache/how-to/cache-keys/

As does Fastly:
  https://docs.fastly.com/en/guides/making-query-strings-agnostic
  https://www.fastly.com/documentation/solutions/examples/manipulate-query-string/

As does Akamai (apparently, based upon the information available):
  https://community.akamai.com/customers/s/article/Remove-query-strings-from-forward-request-and-cache-key?language=en_US

I know Varnish supports this as well; I've done it with Squid (using a helper) too. Not sure about eg nginx or Apache httpd.

So I suspect it's safe to say there's interest in this general feature from people who use HTTP caches. 

The difference here is the control mechanism to invoke that behaviour -- putting it in a response header is really nice because it's a) standardised, so (eventually) interoperable across implementations, and b) driven by the resource on the origin server, who has the most information about the URL's semantics (rather than relying on out-of-band configuration).

However, when a cache has multiple stored responses and they have conflicting information about the cache key, we need to be careful about specifying the interaction. In a way, this is similar to Vary -- it faced a similar question, and the decisions made in its design made implementation difficult. We chose a different approach in Key and Variants to address that; we should probably have a similar discussion here.

Cheers,


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

Received on Tuesday, 19 March 2024 06:26:14 UTC