Re: No-Vary-Search

Jeremy Roman <jbroman@chromium.org> Tue, 18 June 2024 21:32 UTC

Resent-Date: Tue, 18 Jun 2024 21:31:49 +0000
Resent-Message-Id: <E1sJgQf-00GgKA-1I@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of chromium.org designates 2a00:1450:4864:20::633 as permitted sender) client-ip=2a00:1450:4864:20::633; envelope-from=jbroman@chromium.org; helo=mail-ej1-x633.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>
In-Reply-To: <CAEmMwDwxpy7QvJBx01WZpHmH=c2QKE6Q7iBAQisNSqRaxBoz3Q@mail.gmail.com>
From: Jeremy Roman <jbroman@chromium.org>
Date: Tue, 18 Jun 2024 17:31:29 -0400
Message-ID: <CACuR13fENsddR_-3NK+w8w5OvcOwnyt=_eiHsK0E0S2X4rr=ZQ@mail.gmail.com>
To: Rory Hewitt <rory.hewitt@gmail.com>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000d16787061b30ce6f"
Subject: Re: No-Vary-Search
Archived-At: <https://www.w3.org/mid/CACuR13fENsddR_-3NK+w8w5OvcOwnyt=_eiHsK0E0S2X4rr=ZQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On Tue, Jun 18, 2024 at 4:42 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:

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

Very reasonable to point out that examples that better explain this could
be added. To give some inline here for now:

*Cases where the server ignores order, but the client pages may not
consistently order keys.*
No-Vary-Search: key-order
https://example.com/products?color=red&size=medium
https://example.com/products?size=medium&color=red

*Cases where a server has parameters which affect processing but not the
response (at least, semantically). For example, it might prioritize the
request, route it to different backend instances, or mark it with a label
for debugging.*
No-Vary-Search: params=("processing_priority")
https://example.com/search?q=vancouver&processing_priority=userblocking
https://example.com/search?q=vancouver&processing_priority=background

*Cases where there are parameters which are only processed by client-side
script (e.g., to initialize client state)*
No-Vary-Search: params=("zoom")
https://example.com/map?q=vancouver&zoom=5
https://example.com/map?q=vancouver&zoom=9

*Cases where there are parameters which are not yet known when loading
(esp. preloading) happens, but which can be processed client-side*
No-Vary-Search: params=("via")
https://example.com/search?q=vancouver&via=homepage_banner
https://example.com/search?q=vancouver&via=destinations_sidebar

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


> 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