Re: No-Vary-Search

gs-lists-ietf-http-wg@gluelogic.com Tue, 18 June 2024 22:50 UTC

Resent-Date: Tue, 18 Jun 2024 22:49:43 +0000
Resent-Message-Id: <E1sJhe3-00GqQn-0V@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gluelogic.com designates 52.86.233.228 as permitted sender) client-ip=52.86.233.228; envelope-from=gs-lists-ietf-http-wg@gluelogic.com; helo=smtp1.atof.net;
Date: Tue, 18 Jun 2024 18:49:27 -0400
From: gs-lists-ietf-http-wg@gluelogic.com
To: David Benjamin <davidben@chromium.org>
Cc: Rory Hewitt <rory.hewitt@gmail.com>, Jeremy Roman <jbroman@chromium.org>, ietf-http-wg@w3.org
Message-ID: <ZnIO9wjarnurq7XV@xps13>
References: <CACuR13cnHHoRv_Z-HtJeOyJqZb7AVU-_udQ=R_x9qQ1_JeP=KQ@mail.gmail.com> <CAEmMwDwZ8RB0Zz5GCbPeSFH-1tVgTW-hy4_0Fd1L90hNi3h0RA@mail.gmail.com> <CAEmMwDwxpy7QvJBx01WZpHmH=c2QKE6Q7iBAQisNSqRaxBoz3Q@mail.gmail.com> <CACuR13fENsddR_-3NK+w8w5OvcOwnyt=_eiHsK0E0S2X4rr=ZQ@mail.gmail.com> <CAEmMwDyMZz89pRY9OPimPDR1+-nULW9ZC8DjcYfOWvuWjUdtYA@mail.gmail.com> <CAF8qwaCo1gfWaUmSi+V3_bth_Ng8id6UWvY7BeKKA4h3WuMT9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAF8qwaCo1gfWaUmSi+V3_bth_Ng8id6UWvY7BeKKA4h3WuMT9A@mail.gmail.com>
Subject: Re: No-Vary-Search
Archived-At: <https://www.w3.org/mid/ZnIO9wjarnurq7XV@xps13>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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

No-Vary-Search Jeremy Roman
Re: No-Vary-Search Mark Nottingham
Re: No-Vary-Search Jeremy Roman
Re: No-Vary-Search Mark Nottingham
Re: No-Vary-Search Jeremy Roman
Re: No-Vary-Search gs-lists-ietf-http-wg
Re: No-Vary-Search Jeremy Roman
Re: No-Vary-Search gs-lists-ietf-http-wg
Re: No-Vary-Search Mark Nottingham
Re: No-Vary-Search gs-lists-ietf-http-wg
Re: No-Vary-Search Rory Hewitt
Re: No-Vary-Search Rory Hewitt
Re: No-Vary-Search Jeremy Roman
Re: No-Vary-Search Rory Hewitt
Re: No-Vary-Search David Benjamin
Re: No-Vary-Search Rory Hewitt
Re: No-Vary-Search Rory Hewitt
Re: No-Vary-Search Watson Ladd
Re: No-Vary-Search Jeremy Roman
Re: No-Vary-Search gs-lists-ietf-http-wg