Re: No-Vary-Search

IIUC bikeshedding doesn't affect a call for adoption, so happy to discuss
further whenever the appropriate time in the IETF process comes. (Though
this name is already the output of a previous round of bikeshedding within
the W3C process and is in use, so I admit a little reluctance to change it
unless we find a name worth the hassle of a change & deprecation process.)

On Tue, Jun 18, 2024 at 6:53 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Tue, Jun 18, 2024 at 3:47 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:
> >
> > <bikeshedding>
> >
> > Well I'm basing my "it's about caching" argument on both the RFC draft
> itself and also the excellent explainer at
> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md which
> is explicitly all about caching :)
> >
> > I think we (and others?) agree that "search" isn't a good name segment
> due to its multiple meanings. Personally, I think using the "no-" prefix
> isn't necessarily helpful, since this header can be used to specify what
> should and should not be part of the cache key. So my preference would be
> for it to be "Vary-Cache" or "Vary-Params" or "Cache-Params".
> >
> > </bikeshedding>
>
> Except that Vary works the other way, and Cache-Params would be params
> we send to the cache. So No-Vary-URL-Params is I think a better name
> than all of those.
> >
> > On Tue, Jun 18, 2024 at 3:34 PM David Benjamin <davidben@chromium.org>
> wrote:
> >>
> >> <bikeshed>
> >> I think No-Vary-Cache is a worse header name than No-Vary-Search. It
> says nothing about the URL query/search field and could just as easily
> describe the HTTP request headers or other things that the response doesn't
> vary on. That means it should include something that indicates the URL
> query/search field.
> >>
> >> As for the Cache part, it's not really a statement about the cache
> anyway. It's a statement about whether the response to this request varies
> on some property. The cache is just the primary reason for the client to
> care about this information. So, matching the precedent with the Vary
> header, I think "Vary" is enough to capture this aspect of the name without
> adding "Cache".
> >>
> >> I agree the combination of the two is awkward. It's unfortunate that
> "search" is a bit overloaded of a term, and everywhere is inconsistent
> about whether it's the "query" or the "search", but removing any reference
> to the field at all is even worse. (Tossing out an idea without opinion,
> No-Vary-(Search|Query|URL)-Params? It's really the individual params being
> targeted and not the overall search/query string.)
> >> </bikeshed>
>
>
>
> --
> Astra mortemque praestare gradatim
>