Re: No-Vary-Search

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

Resent-Date: Tue, 18 Jun 2024 20:42:38 +0000
Resent-Message-Id: <E1sJff4-00GaSH-0b@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::42f as permitted sender) client-ip=2a00:1450:4864:20::42f; envelope-from=roryhewitt@gmail.com; helo=mail-wr1-x42f.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>
In-Reply-To: <CAEmMwDwZ8RB0Zz5GCbPeSFH-1tVgTW-hy4_0Fd1L90hNi3h0RA@mail.gmail.com>
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Tue, 18 Jun 2024 13:42:18 -0700
Message-ID: <CAEmMwDwxpy7QvJBx01WZpHmH=c2QKE6Q7iBAQisNSqRaxBoz3Q@mail.gmail.com>
To: Jeremy Roman <jbroman@chromium.org>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000d21e35061b301ea4"
Subject: Re: No-Vary-Search
Archived-At: <https://www.w3.org/mid/CAEmMwDwxpy7QvJBx01WZpHmH=c2QKE6Q7iBAQisNSqRaxBoz3Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hi Jeremy,

In the two examples sections, can you provide an example of a URL and show
how specifying this header will change caching - your examples give some
"Input => Result" answers in a table, but I think an actual sample URL
(e.g. https://www.example.com?you=cool&me=notcool) showing the effect of
various header values affect how the content should be cached would be
useful.

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 think this document needs a high-level overview section, explaining what
> you're trying to do and what specific problems you're trying to solve.
> You're clearly deep in the weeds on it (I don't mean that pejoratively!)
> but for those of us that are coming at it fresh, it needs something there
> to tell us about the idea/project.
>
> On Tue, Feb 20, 2024 at 6:14 PM Jeremy Roman <jbroman@chromium.org> wrote:
>
>> Hello HTTPWG:
>>
>> This is tangentially unrelated to my previous email, but I've split it
>> into another thread to avoid entangling the two.
>>
>> A developer previously reported to us that their ability to use the
>> prefetch cache was limited because their prefetch request URLs needed to
>> include certain query parameters which are different from the navigation
>> request URL, even though these URLs do not affect the resource the server
>> ultimately produces (and therefore, the client can safely use the
>> resource). The explainer
>> <https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md> we
>> wrote goes through some of the possible use cases in more detail.
>>
>> The semantics we have right now (and the header name, No-Vary-Search¹)
>> are designed with the concept of being implementable in non-browser HTTP
>> implementations, but since browser use cases were what we are focused on,
>> there are some places where the semantics rely on, e.g., WHATWG URL
>> <https://url.spec.whatwg.org/>, which may vary in subtle ways from other
>> concepts of the meaning of the query string (since IETF HTTP doesn't
>> currently take a position on that as far as I know).
>>
>> The specification draft
>> <https://wicg.github.io/nav-speculation/no-vary-search.html> is
>> currently hosted by the W3C's Web Incubator Community Group (WICG) and
>> we've previously discussed it in a W3C context, but it was suggested that
>> we bring it to HTTPWG's attention, too, and if there is interest among
>> participants it could migrate to an HTTPWG RFC instead of continuing
>> incubation in the web standards venues.
>>
>> ¹ 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.
>>
>

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