Re: No-Vary-Search

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

On Tue, Jun 18, 2024 at 6:14 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:

> <bikeshedding>
>
> Oh, I get the idea to extend/build upon/mimic/evoke the Vary header, and
> FWIW, I really like the general 'No-Vary' idea. I'm just concerned about
> the specific 'No-Vary-Search' name, as it implies something to do with the
> generally understood concept of 'search' (y'know, searching for things) and
> honestly, I'd completely forgotten that the query string is sometimes
> called the 'search' part of the URL. It's a weirdly technical use of that
> term that few outside the IETF/W3C would either know or understand. But
> here we are...
>
> Since this header is about how user agents should cache content where that
> content may be accessed via similar but slightly different URLs, maybe
> 'Vary-Cache' is also an option? This more generic name would also enable
> the header to be extended in the future to cover things in addition to the
> URL query parameters without the name becoming out-of-date.
>
> But all of this may just be me being grumpy and objecting to the use of
> 'search' in its technical meaning rather than its commonly-used meaning.
>
> </bikeshedding>
>
> On Tue, Jun 18, 2024 at 2:31 PM Jeremy Roman <jbroman@chromium.org> wrote:
>
>> On Tue, Jun 18, 2024 at 1:20 PM Rory Hewitt <rory.hewitt@gmail.com>
>>> wrote:
>>>
>>>> Hey Jeremy,
>>>>
>>>> > This was originally No-Vary-Query, but the web-exposed APIs call
>>>> this part of the URL "search", so this change was requested in a W3C
>>>> discussion.
>>>>
>>>> I can understand why you changed the name from "No-Vary-Query", but
>>>> given that it's primarily a mechanism to change the way that content is
>>>> cached, I think it makes sense to call it "No-Vary-Cache"
>>>>
>>>
>> I'll avoid getting too deep into bikeshed painting, but briefly: I hoped
>> to evoke the longstanding Vary header
>> <https://www.rfc-editor.org/rfc/rfc9110#field.vary>.
>>
>