Re: No-Vary-Search

Jeremy Roman <jbroman@chromium.org> Fri, 28 June 2024 18:48 UTC

Resent-Date: Fri, 28 Jun 2024 18:47:16 +0000
Resent-Message-Id: <E1sNGcu-00609e-26@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of chromium.org designates 2a00:1450:4864:20::62e as permitted sender) client-ip=2a00:1450:4864:20::62e; envelope-from=jbroman@chromium.org; helo=mail-ej1-x62e.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> <CAEmMwDyMZz89pRY9OPimPDR1+-nULW9ZC8DjcYfOWvuWjUdtYA@mail.gmail.com> <CAF8qwaCo1gfWaUmSi+V3_bth_Ng8id6UWvY7BeKKA4h3WuMT9A@mail.gmail.com> <CAEmMwDxN-SGQemcmTEoYS4YfVV23Q21c+Y_ePk4X7i4oTfn9hQ@mail.gmail.com> <CACsn0c=gQfmnTg=MMC427cphqXtx5zfqEnuZnkGaza1fNBBZqw@mail.gmail.com>
In-Reply-To: <CACsn0c=gQfmnTg=MMC427cphqXtx5zfqEnuZnkGaza1fNBBZqw@mail.gmail.com>
From: Jeremy Roman <jbroman@chromium.org>
Date: Fri, 28 Jun 2024 14:46:57 -0400
Message-ID: <CACuR13dmf4Hb38MTSyw-f6MgM9DFugFj3a2fmcp0jnKCxCJU-w@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Rory Hewitt <rory.hewitt@gmail.com>, David Benjamin <davidben@chromium.org>, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000c27078061bf7acc2"
Subject: Re: No-Vary-Search
Archived-At: <https://www.w3.org/mid/CACuR13dmf4Hb38MTSyw-f6MgM9DFugFj3a2fmcp0jnKCxCJU-w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

IIUC bikeshedding doesn't affect a call for adoption, so happy to discuss
further whenever the appropriate time in the IETF process comes. (Though
this name is already the output of a previous round of bikeshedding within
the W3C process and is in use, so I admit a little reluctance to change it
unless we find a name worth the hassle of a change & deprecation process.)

On Tue, Jun 18, 2024 at 6:53 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Tue, Jun 18, 2024 at 3:47 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:
> >
> > <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>
>
> Except that Vary works the other way, and Cache-Params would be params
> we send to the cache. So No-Vary-URL-Params is I think a better name
> than all of those.
> >
> > 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>
>
>
>
> --
> Astra mortemque praestare gradatim
>

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