Re: No-Vary-Search

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