Re: No-Vary-Search

In the interest of continuing discussion on this list, the WICG draft has
been reformatted in RFC format and reported to the Datatracker:

https://datatracker.ietf.org/doc/draft-wicg-http-no-vary-search/01/
or directly on GitHub
https://jeremyroman.github.io/http-no-vary-search/draft-wicg-http-no-vary-search.html

The text has been left mostly unchanged so far (modulo very small editorial
changes), and does not yet reflect any change to RFC 9111 behavior (though
hopefully it's clear what those changes would be, from the existing text).

On Tue, Mar 19, 2024 at 2:26 AM Mark Nottingham <mnot@mnot.net> wrote:

> 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/
>
>