Re: No-Vary-Search

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

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