Re: No-Vary-Search

[[e-mail]]

More bikeshed: what are the advantages of a standalone header versus
extending Cache-Control?  Structured fields is one advantage of a
new, standaone header.

Cheers, Glenn

On Tue, Jun 18, 2024 at 06:34:31PM -0400, David Benjamin 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>
> 
> On Tue, Jun 18, 2024 at 6:14 PM Rory Hewitt <[e-mail]> 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 <[e-mail]> wrote:
> >
> >> On Tue, Jun 18, 2024 at 1:20 PM Rory Hewitt <[e-mail]>
> >>> 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>.
> >>
> >