Re: No-Vary-Search

Rory Hewitt <rory.hewitt@gmail.com> Tue, 18 June 2024 22:12 UTC

Resent-Date: Tue, 18 Jun 2024 22:11:36 +0000
Resent-Message-Id: <E1sJh3A-00GlY2-0N@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::435 as permitted sender) client-ip=2a00:1450:4864:20::435; envelope-from=roryhewitt@gmail.com; helo=mail-wr1-x435.google.com;
MIME-Version: 1.0
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>
In-Reply-To: <CACuR13fENsddR_-3NK+w8w5OvcOwnyt=_eiHsK0E0S2X4rr=ZQ@mail.gmail.com>
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Tue, 18 Jun 2024 15:11:16 -0700
Message-ID: <CAEmMwDyMZz89pRY9OPimPDR1+-nULW9ZC8DjcYfOWvuWjUdtYA@mail.gmail.com>
To: Jeremy Roman <jbroman@chromium.org>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000f51b37061b315c82"
Subject: Re: No-Vary-Search
Archived-At: <https://www.w3.org/mid/CAEmMwDyMZz89pRY9OPimPDR1+-nULW9ZC8DjcYfOWvuWjUdtYA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

<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