Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[David Benjamin]

Additionally, even if Chromium currently only uses it for prefetch logic,
the semantics seem to be about general HTTP caching. There's tons of
interest and expertise in httpbis around caching and how to optimize it, so
it's definitely the right venue for this work. I expect you'll find many
people there who would be interested in this, and with useful perspectives
on how best to do it. I'll echo David here and also offer to help with
pointers.

On Fri, Nov 10, 2023 at 2:49 PM 'David Schinazi' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi folks,
>
> As an amusing coincidence, I'm sitting in an HTTPBIS WG meeting in Prague
> at IETF 118.
>
> HTTP headers are controlled by an IANA registry
> , so for
> this spec to progress it would need to register the header there. Per the
> process for that specific registry, that'll require review from either of
> the designated experts: Mark Nottingham or Roy Fielding. Mark in on
> the Board of Directors of the W3C so you might have met him there. I can't
> speak for him, but I suspect that he'd encourage you to come present this
> work to IETF. I sympathise with how daunting the IETF process might feel
> from the outside, but that is the place you'll need to go for HTTP headers
> regardless of whether you have experience with it. I'm happy to provide
> assistance in how to approach it, and will note that multiple of your
> teammates are regular IETF attendees and I'm sure they'd also be willing to
> help move this forward here. The sooner this is brought to the IETF, the
> sooner any changes made there can be acted on.
>
> Hope this helps,
> David
>
>
> On Fri, Nov 10, 2023 at 12:34 PM Yoav Weiss 
> wrote:
>
>> LGTM3 but please invest a bit of time before shipping to make sure
>> bikeshedding isn't in the future here.
>>
>> Specifically, I hear that HTTPWG folks are pushing for a compression
>> dictionary rename of its match functionality from "search" to "query". It'd
>> be good to ensure that won't be a hurdle this feature would run into
>> further down that same road.
>>
>> On Fri, Nov 10, 2023 at 9:44 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> 2023年11月10日(金) 17:14 Yoav Weiss :
>>>


 On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola 
 wrote:

>
>
> On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss 
> wrote:
>
>> Thanks for working on this, as I'm enthusiastically supportive of
>> tackling this use case!
>>
>> One thing I wish y'all have done, and that I haven't seen any
>> evidence of (but please correct me if I'm wrong) is discuss this design
>> with the HTTPWG at the IETF.
>> That is feedback that I believe you got at TPAC 22, as well as on the
>> TAG review.
>> While this is not strictly blocking this intent (as the prefetch
>> cache is a web concept), as the explainer rightfully states, this is a
>> concept that can very well be expanded to encompass HTTP caches, both
>> inside and outside the browser. It'd be great if that eventual expansion 
>> is
>> compatible with the prefetch cache.
>>
>> Would y'all be open to bringing the design to discussion at the
>> HTTPWG, and potentially move the header's semantic definition there? 
>> (while
>> eventually moving the web processing model to a web standards venue)
>>
>> +David Schinazi  for his thoughts on the above
>>
>
> Hi Yoav,
>
> We're very open to discussing this with the HTTPWG, and have had
> informal discussions with HTTPWG members at TPAC and other venues.
>

 That's great to hear!


> Our plan was to do so as part of graduation from incubation, and/or as
> this expanded beyond the preloading caches into the network stack. See
> https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
> .
>
> The IETF process is outside of the preloading teams' expertise, and
> (as you noted) the IETF's layers of the technology stack are not involved
> in what's being shipped here.
>

 I agree. One concern on that front is that HTTPWG discussions would
 result in non-backwards-compatible changes to the related headers, or even
 result in divergence. It'd be a shame if we end up with multiple headers
 that do the same thing in different caching layers.

 At the same time, I don't think there's a need to block this intent on
 that process, assuming y'all would be willing to ensure such divergence
 does not happen. (either by satisfying the HTTP cache use cases through
 backwards compatible changes, or by taking a compat hit if needed)

 Would this work for y'all?

>>>
>>> Yes, we're definitely willing to ensure this. Thanks for raising the
>>> concern!
>>>
>>>

> But if you'd like to see such engagement before we get to incubation
> graduation or start the networking implementatio

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

['David Schinazi' via blink-dev]

Hi folks,

As an amusing coincidence, I'm sitting in an HTTPBIS WG meeting in Prague
at IETF 118.

HTTP headers are controlled by an IANA registry
, so for
this spec to progress it would need to register the header there. Per the
process for that specific registry, that'll require review from either of
the designated experts: Mark Nottingham or Roy Fielding. Mark in on
the Board of Directors of the W3C so you might have met him there. I can't
speak for him, but I suspect that he'd encourage you to come present this
work to IETF. I sympathise with how daunting the IETF process might feel
from the outside, but that is the place you'll need to go for HTTP headers
regardless of whether you have experience with it. I'm happy to provide
assistance in how to approach it, and will note that multiple of your
teammates are regular IETF attendees and I'm sure they'd also be willing to
help move this forward here. The sooner this is brought to the IETF, the
sooner any changes made there can be acted on.

Hope this helps,
David


On Fri, Nov 10, 2023 at 12:34 PM Yoav Weiss  wrote:

> LGTM3 but please invest a bit of time before shipping to make sure
> bikeshedding isn't in the future here.
>
> Specifically, I hear that HTTPWG folks are pushing for a compression
> dictionary rename of its match functionality from "search" to "query". It'd
> be good to ensure that won't be a hurdle this feature would run into
> further down that same road.
>
> On Fri, Nov 10, 2023 at 9:44 AM Domenic Denicola 
> wrote:
>
>>
>>
>> 2023年11月10日(金) 17:14 Yoav Weiss :
>>
>>>
>>>
>>> On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola 
>>> wrote:
>>>


 On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss 
 wrote:

> Thanks for working on this, as I'm enthusiastically supportive of
> tackling this use case!
>
> One thing I wish y'all have done, and that I haven't seen any evidence
> of (but please correct me if I'm wrong) is discuss this design with the
> HTTPWG at the IETF.
> That is feedback that I believe you got at TPAC 22, as well as on the
> TAG review.
> While this is not strictly blocking this intent (as the prefetch cache
> is a web concept), as the explainer rightfully states, this is a concept
> that can very well be expanded to encompass HTTP caches, both inside and
> outside the browser. It'd be great if that eventual expansion is 
> compatible
> with the prefetch cache.
>
> Would y'all be open to bringing the design to discussion at the
> HTTPWG, and potentially move the header's semantic definition there? 
> (while
> eventually moving the web processing model to a web standards venue)
>
> +David Schinazi  for his thoughts on the above
>

 Hi Yoav,

 We're very open to discussing this with the HTTPWG, and have had
 informal discussions with HTTPWG members at TPAC and other venues.

>>>
>>> That's great to hear!
>>>
>>>
 Our plan was to do so as part of graduation from incubation, and/or as
 this expanded beyond the preloading caches into the network stack. See
 https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
 .

 The IETF process is outside of the preloading teams' expertise, and (as
 you noted) the IETF's layers of the technology stack are not involved in
 what's being shipped here.

>>>
>>> I agree. One concern on that front is that HTTPWG discussions would
>>> result in non-backwards-compatible changes to the related headers, or even
>>> result in divergence. It'd be a shame if we end up with multiple headers
>>> that do the same thing in different caching layers.
>>>
>>> At the same time, I don't think there's a need to block this intent on
>>> that process, assuming y'all would be willing to ensure such divergence
>>> does not happen. (either by satisfying the HTTP cache use cases through
>>> backwards compatible changes, or by taking a compat hit if needed)
>>>
>>> Would this work for y'all?
>>>
>>
>> Yes, we're definitely willing to ensure this. Thanks for raising the
>> concern!
>>
>>
>>>
 But if you'd like to see such engagement before we get to incubation
 graduation or start the networking implementation, then we'd love your help
 making those connections and working through the process!

>>>
>>> Generally I think engaging earlier would be better. Happy to intro and
>>> outline the IETF process. +Patrick Meenan  and
>>> David are also likely to have contacts and insights.
>>>
>>>

>
> On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell 
> wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2023-11-07 01:57, Mike Taylor wrote:
>>
>> Thanks Liviu.
>>
>> I've spent some time today reviewing the explainer and spec, and find
>> the use cases compelling.
>>
>> LGTM1 to ship. A non-blocking request would be to add the security

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Yoav Weiss]

LGTM3 but please invest a bit of time before shipping to make sure
bikeshedding isn't in the future here.

Specifically, I hear that HTTPWG folks are pushing for a compression
dictionary rename of its match functionality from "search" to "query". It'd
be good to ensure that won't be a hurdle this feature would run into
further down that same road.

On Fri, Nov 10, 2023 at 9:44 AM Domenic Denicola 
wrote:

>
>
> 2023年11月10日(金) 17:14 Yoav Weiss :
>
>>
>>
>> On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss 
>>> wrote:
>>>
 Thanks for working on this, as I'm enthusiastically supportive of
 tackling this use case!

 One thing I wish y'all have done, and that I haven't seen any evidence
 of (but please correct me if I'm wrong) is discuss this design with the
 HTTPWG at the IETF.
 That is feedback that I believe you got at TPAC 22, as well as on the
 TAG review.
 While this is not strictly blocking this intent (as the prefetch cache
 is a web concept), as the explainer rightfully states, this is a concept
 that can very well be expanded to encompass HTTP caches, both inside and
 outside the browser. It'd be great if that eventual expansion is compatible
 with the prefetch cache.

 Would y'all be open to bringing the design to discussion at the HTTPWG,
 and potentially move the header's semantic definition there? (while
 eventually moving the web processing model to a web standards venue)

 +David Schinazi  for his thoughts on the above

>>>
>>> Hi Yoav,
>>>
>>> We're very open to discussing this with the HTTPWG, and have had
>>> informal discussions with HTTPWG members at TPAC and other venues.
>>>
>>
>> That's great to hear!
>>
>>
>>> Our plan was to do so as part of graduation from incubation, and/or as
>>> this expanded beyond the preloading caches into the network stack. See
>>> https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
>>> .
>>>
>>> The IETF process is outside of the preloading teams' expertise, and (as
>>> you noted) the IETF's layers of the technology stack are not involved in
>>> what's being shipped here.
>>>
>>
>> I agree. One concern on that front is that HTTPWG discussions would
>> result in non-backwards-compatible changes to the related headers, or even
>> result in divergence. It'd be a shame if we end up with multiple headers
>> that do the same thing in different caching layers.
>>
>> At the same time, I don't think there's a need to block this intent on
>> that process, assuming y'all would be willing to ensure such divergence
>> does not happen. (either by satisfying the HTTP cache use cases through
>> backwards compatible changes, or by taking a compat hit if needed)
>>
>> Would this work for y'all?
>>
>
> Yes, we're definitely willing to ensure this. Thanks for raising the
> concern!
>
>
>>
>>> But if you'd like to see such engagement before we get to incubation
>>> graduation or start the networking implementation, then we'd love your help
>>> making those connections and working through the process!
>>>
>>
>> Generally I think engaging earlier would be better. Happy to intro and
>> outline the IETF process. +Patrick Meenan  and David
>> are also likely to have contacts and insights.
>>
>>
>>>

 On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell 
 wrote:

> LGTM2
>
> /Daniel
> On 2023-11-07 01:57, Mike Taylor wrote:
>
> Thanks Liviu.
>
> I've spent some time today reviewing the explainer and spec, and find
> the use cases compelling.
>
> LGTM1 to ship. A non-blocking request would be to add the security &
> privacy considerations from the explainer into the draft WICG spec (or
> something similar).
>
> (Also, kudos to all who contributed to the explainer - it's very
> thorough and answered every question I had as I began to review in depth.
> Excellent work.)
> On 11/6/23 5:08 PM, Liviu Tinta wrote:
>
> > Are there any open issues that would result in breaking changes,
> after we ship?
>
> There are 2 open issues related to No-Vary-Search:
> https://github.com/WICG/nav-speculation/labels/no-vary-search. None
> of the open issues requires modifying No-Vary-Search header. We are not
> expecting breaking changes after we ship.
>
> On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:
>
>> On 11/1/23 9:59 AM, Liviu Tinta wrote:
>>
>> Contact emails dome...@chromium.org, jbro...@chromium.org,
>> liviuti...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
>>
>> Specification
>> https://wicg.github.io/nav-speculation/no-vary-search.html
>>
>> Summary
>>
>> Enables prefetch to match even if URL query parameters change. The
>> No-Vary-Search HTTP response header declares that

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Domenic Denicola]

2023年11月10日(金) 17:14 Yoav Weiss :

>
>
> On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks for working on this, as I'm enthusiastically supportive of
>>> tackling this use case!
>>>
>>> One thing I wish y'all have done, and that I haven't seen any evidence
>>> of (but please correct me if I'm wrong) is discuss this design with the
>>> HTTPWG at the IETF.
>>> That is feedback that I believe you got at TPAC 22, as well as on the
>>> TAG review.
>>> While this is not strictly blocking this intent (as the prefetch cache
>>> is a web concept), as the explainer rightfully states, this is a concept
>>> that can very well be expanded to encompass HTTP caches, both inside and
>>> outside the browser. It'd be great if that eventual expansion is compatible
>>> with the prefetch cache.
>>>
>>> Would y'all be open to bringing the design to discussion at the HTTPWG,
>>> and potentially move the header's semantic definition there? (while
>>> eventually moving the web processing model to a web standards venue)
>>>
>>> +David Schinazi  for his thoughts on the above
>>>
>>
>> Hi Yoav,
>>
>> We're very open to discussing this with the HTTPWG, and have had informal
>> discussions with HTTPWG members at TPAC and other venues.
>>
>
> That's great to hear!
>
>
>> Our plan was to do so as part of graduation from incubation, and/or as
>> this expanded beyond the preloading caches into the network stack. See
>> https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
>> .
>>
>> The IETF process is outside of the preloading teams' expertise, and (as
>> you noted) the IETF's layers of the technology stack are not involved in
>> what's being shipped here.
>>
>
> I agree. One concern on that front is that HTTPWG discussions would result
> in non-backwards-compatible changes to the related headers, or even result
> in divergence. It'd be a shame if we end up with multiple headers that do
> the same thing in different caching layers.
>
> At the same time, I don't think there's a need to block this intent on
> that process, assuming y'all would be willing to ensure such divergence
> does not happen. (either by satisfying the HTTP cache use cases through
> backwards compatible changes, or by taking a compat hit if needed)
>
> Would this work for y'all?
>

Yes, we're definitely willing to ensure this. Thanks for raising the
concern!


>
>> But if you'd like to see such engagement before we get to incubation
>> graduation or start the networking implementation, then we'd love your help
>> making those connections and working through the process!
>>
>
> Generally I think engaging earlier would be better. Happy to intro and
> outline the IETF process. +Patrick Meenan  and David
> are also likely to have contacts and insights.
>
>
>>
>>>
>>> On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell 
>>> wrote:
>>>
 LGTM2

 /Daniel
 On 2023-11-07 01:57, Mike Taylor wrote:

 Thanks Liviu.

 I've spent some time today reviewing the explainer and spec, and find
 the use cases compelling.

 LGTM1 to ship. A non-blocking request would be to add the security &
 privacy considerations from the explainer into the draft WICG spec (or
 something similar).

 (Also, kudos to all who contributed to the explainer - it's very
 thorough and answered every question I had as I began to review in depth.
 Excellent work.)
 On 11/6/23 5:08 PM, Liviu Tinta wrote:

 > Are there any open issues that would result in breaking changes,
 after we ship?

 There are 2 open issues related to No-Vary-Search:
 https://github.com/WICG/nav-speculation/labels/no-vary-search. None of
 the open issues requires modifying No-Vary-Search header. We are not
 expecting breaking changes after we ship.

 On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:

> On 11/1/23 9:59 AM, Liviu Tinta wrote:
>
> Contact emails dome...@chromium.org, jbro...@chromium.org,
> liviuti...@chromium.org
>
> Explainer
> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
>
> Specification
> https://wicg.github.io/nav-speculation/no-vary-search.html
>
> Summary
>
> Enables prefetch to match even if URL query parameters change. The
> No-Vary-Search HTTP response header declares that some or all parts of a
> URL's query can be ignored for cache matching purposes. It can declare 
> that
> the order of query parameter keys should not cause cache misses, that
> specific query parameters should not cause cache misses or that only
> certain known query parameters should cause cache misses. It could apply 
> to
> multiple caches, but this entry refers to support for prefetch cache.
>
> We would like to ship "No-Vary-Search support in navigation prefetch
> cache" together with "No-Vary

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Yoav Weiss]

On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola 
wrote:

>
>
> On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss  wrote:
>
>> Thanks for working on this, as I'm enthusiastically supportive of
>> tackling this use case!
>>
>> One thing I wish y'all have done, and that I haven't seen any evidence of
>> (but please correct me if I'm wrong) is discuss this design with the HTTPWG
>> at the IETF.
>> That is feedback that I believe you got at TPAC 22, as well as on the TAG
>> review.
>> While this is not strictly blocking this intent (as the prefetch cache is
>> a web concept), as the explainer rightfully states, this is a concept that
>> can very well be expanded to encompass HTTP caches, both inside and outside
>> the browser. It'd be great if that eventual expansion is compatible with
>> the prefetch cache.
>>
>> Would y'all be open to bringing the design to discussion at the HTTPWG,
>> and potentially move the header's semantic definition there? (while
>> eventually moving the web processing model to a web standards venue)
>>
>> +David Schinazi  for his thoughts on the above
>>
>
> Hi Yoav,
>
> We're very open to discussing this with the HTTPWG, and have had informal
> discussions with HTTPWG members at TPAC and other venues.
>

That's great to hear!


> Our plan was to do so as part of graduation from incubation, and/or as
> this expanded beyond the preloading caches into the network stack. See
> https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
> .
>
> The IETF process is outside of the preloading teams' expertise, and (as
> you noted) the IETF's layers of the technology stack are not involved in
> what's being shipped here.
>

I agree. One concern on that front is that HTTPWG discussions would result
in non-backwards-compatible changes to the related headers, or even result
in divergence. It'd be a shame if we end up with multiple headers that do
the same thing in different caching layers.

At the same time, I don't think there's a need to block this intent on that
process, assuming y'all would be willing to ensure such divergence does not
happen. (either by satisfying the HTTP cache use cases through backwards
compatible changes, or by taking a compat hit if needed)

Would this work for y'all?


> But if you'd like to see such engagement before we get to incubation
> graduation or start the networking implementation, then we'd love your help
> making those connections and working through the process!
>

Generally I think engaging earlier would be better. Happy to intro and
outline the IETF process. +Patrick Meenan  and David
are also likely to have contacts and insights.


>
>>
>> On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell 
>> wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2023-11-07 01:57, Mike Taylor wrote:
>>>
>>> Thanks Liviu.
>>>
>>> I've spent some time today reviewing the explainer and spec, and find
>>> the use cases compelling.
>>>
>>> LGTM1 to ship. A non-blocking request would be to add the security &
>>> privacy considerations from the explainer into the draft WICG spec (or
>>> something similar).
>>>
>>> (Also, kudos to all who contributed to the explainer - it's very
>>> thorough and answered every question I had as I began to review in depth.
>>> Excellent work.)
>>> On 11/6/23 5:08 PM, Liviu Tinta wrote:
>>>
>>> > Are there any open issues that would result in breaking changes, after
>>> we ship?
>>>
>>> There are 2 open issues related to No-Vary-Search:
>>> https://github.com/WICG/nav-speculation/labels/no-vary-search. None of
>>> the open issues requires modifying No-Vary-Search header. We are not
>>> expecting breaking changes after we ship.
>>>
>>> On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:
>>>
 On 11/1/23 9:59 AM, Liviu Tinta wrote:

 Contact emails dome...@chromium.org, jbro...@chromium.org,
 liviuti...@chromium.org

 Explainer
 https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md

 Specification
 https://wicg.github.io/nav-speculation/no-vary-search.html

 Summary

 Enables prefetch to match even if URL query parameters change. The
 No-Vary-Search HTTP response header declares that some or all parts of a
 URL's query can be ignored for cache matching purposes. It can declare that
 the order of query parameter keys should not cause cache misses, that
 specific query parameters should not cause cache misses or that only
 certain known query parameters should cause cache misses. It could apply to
 multiple caches, but this entry refers to support for prefetch cache.

 We would like to ship "No-Vary-Search support in navigation prefetch
 cache" together with "No-Vary-Search Hint for Prefetch Speculation
 Rules" (https://chromestatus.com/feature/4887338302308352).

 Blink component Internals>Preload
 

 TAG review https://github.com/w3ct

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Domenic Denicola]

On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss  wrote:

> Thanks for working on this, as I'm enthusiastically supportive of tackling
> this use case!
>
> One thing I wish y'all have done, and that I haven't seen any evidence of
> (but please correct me if I'm wrong) is discuss this design with the HTTPWG
> at the IETF.
> That is feedback that I believe you got at TPAC 22, as well as on the TAG
> review.
> While this is not strictly blocking this intent (as the prefetch cache is
> a web concept), as the explainer rightfully states, this is a concept that
> can very well be expanded to encompass HTTP caches, both inside and outside
> the browser. It'd be great if that eventual expansion is compatible with
> the prefetch cache.
>
> Would y'all be open to bringing the design to discussion at the HTTPWG,
> and potentially move the header's semantic definition there? (while
> eventually moving the web processing model to a web standards venue)
>
> +David Schinazi  for his thoughts on the above
>

Hi Yoav,

We're very open to discussing this with the HTTPWG, and have had informal
discussions with HTTPWG members at TPAC and other venues. Our plan was to
do so as part of graduation from incubation, and/or as this expanded beyond
the preloading caches into the network stack. See
https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue
.

The IETF process is outside of the preloading teams' expertise, and (as you
noted) the IETF's layers of the technology stack are not involved in what's
being shipped here. But if you'd like to see such engagement before we get
to incubation graduation or start the networking implementation, then we'd
love your help making those connections and working through the process!


>
> On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2023-11-07 01:57, Mike Taylor wrote:
>>
>> Thanks Liviu.
>>
>> I've spent some time today reviewing the explainer and spec, and find the
>> use cases compelling.
>>
>> LGTM1 to ship. A non-blocking request would be to add the security &
>> privacy considerations from the explainer into the draft WICG spec (or
>> something similar).
>>
>> (Also, kudos to all who contributed to the explainer - it's very thorough
>> and answered every question I had as I began to review in depth. Excellent
>> work.)
>> On 11/6/23 5:08 PM, Liviu Tinta wrote:
>>
>> > Are there any open issues that would result in breaking changes, after
>> we ship?
>>
>> There are 2 open issues related to No-Vary-Search:
>> https://github.com/WICG/nav-speculation/labels/no-vary-search. None of
>> the open issues requires modifying No-Vary-Search header. We are not
>> expecting breaking changes after we ship.
>>
>> On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:
>>
>>> On 11/1/23 9:59 AM, Liviu Tinta wrote:
>>>
>>> Contact emails dome...@chromium.org, jbro...@chromium.org,
>>> liviuti...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
>>>
>>> Specification https://wicg.github.io/nav-speculation/no-vary-search.html
>>>
>>> Summary
>>>
>>> Enables prefetch to match even if URL query parameters change. The
>>> No-Vary-Search HTTP response header declares that some or all parts of a
>>> URL's query can be ignored for cache matching purposes. It can declare that
>>> the order of query parameter keys should not cause cache misses, that
>>> specific query parameters should not cause cache misses or that only
>>> certain known query parameters should cause cache misses. It could apply to
>>> multiple caches, but this entry refers to support for prefetch cache.
>>>
>>> We would like to ship "No-Vary-Search support in navigation prefetch
>>> cache" together with "No-Vary-Search Hint for Prefetch Speculation
>>> Rules" (https://chromestatus.com/feature/4887338302308352).
>>>
>>> Blink component Internals>Preload
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/797
>>>
>>> TAG review status Positive.
>>>
>>> Chromium Trial Name NoVarySearchPrefetch
>>>
>>> Link to origin trial feedback summary
>>> https://github.com/WICG/nav-speculation/issues
>>>
>>> Are there any open issues that would result in breaking changes, after
>>> we ship?
>>>
>>>
>>> Origin Trial documentation link
>>> https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/717)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/106)
>>>
>>> *Web developers*: Google Search has been experimenting with No-Vary-Search
>>> header / Speculation Rules "expects_no_vary_search". This functionality
>>> helps Google Search to match prefetched content to the next user
>>> navigation. Developers can use parameters in the prefetched URL t

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Yoav Weiss]

Thanks for working on this, as I'm enthusiastically supportive of tackling
this use case!

One thing I wish y'all have done, and that I haven't seen any evidence of
(but please correct me if I'm wrong) is discuss this design with the HTTPWG
at the IETF.
That is feedback that I believe you got at TPAC 22, as well as on the TAG
review.
While this is not strictly blocking this intent (as the prefetch cache is a
web concept), as the explainer rightfully states, this is a concept that
can very well be expanded to encompass HTTP caches, both inside and outside
the browser. It'd be great if that eventual expansion is compatible with
the prefetch cache.

Would y'all be open to bringing the design to discussion at the HTTPWG, and
potentially move the header's semantic definition there? (while eventually
moving the web processing model to a web standards venue)

+David Schinazi  for his thoughts on the above

On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-11-07 01:57, Mike Taylor wrote:
>
> Thanks Liviu.
>
> I've spent some time today reviewing the explainer and spec, and find the
> use cases compelling.
>
> LGTM1 to ship. A non-blocking request would be to add the security &
> privacy considerations from the explainer into the draft WICG spec (or
> something similar).
>
> (Also, kudos to all who contributed to the explainer - it's very thorough
> and answered every question I had as I began to review in depth. Excellent
> work.)
> On 11/6/23 5:08 PM, Liviu Tinta wrote:
>
> > Are there any open issues that would result in breaking changes, after
> we ship?
>
> There are 2 open issues related to No-Vary-Search:
> https://github.com/WICG/nav-speculation/labels/no-vary-search. None of
> the open issues requires modifying No-Vary-Search header. We are not
> expecting breaking changes after we ship.
>
> On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:
>
>> On 11/1/23 9:59 AM, Liviu Tinta wrote:
>>
>> Contact emails dome...@chromium.org, jbro...@chromium.org,
>> liviuti...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
>>
>> Specification https://wicg.github.io/nav-speculation/no-vary-search.html
>>
>> Summary
>>
>> Enables prefetch to match even if URL query parameters change. The
>> No-Vary-Search HTTP response header declares that some or all parts of a
>> URL's query can be ignored for cache matching purposes. It can declare that
>> the order of query parameter keys should not cause cache misses, that
>> specific query parameters should not cause cache misses or that only
>> certain known query parameters should cause cache misses. It could apply to
>> multiple caches, but this entry refers to support for prefetch cache.
>>
>> We would like to ship "No-Vary-Search support in navigation prefetch
>> cache" together with "No-Vary-Search Hint for Prefetch Speculation
>> Rules" (https://chromestatus.com/feature/4887338302308352).
>>
>> Blink component Internals>Preload
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/797
>>
>> TAG review status Positive.
>>
>> Chromium Trial Name NoVarySearchPrefetch
>>
>> Link to origin trial feedback summary
>> https://github.com/WICG/nav-speculation/issues
>>
>> Are there any open issues that would result in breaking changes, after we
>> ship?
>>
>>
>> Origin Trial documentation link
>> https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/717)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/106)
>>
>> *Web developers*: Google Search has been experimenting with No-Vary-Search
>> header / Speculation Rules "expects_no_vary_search". This functionality
>> helps Google Search to match prefetched content to the next user
>> navigation. Developers can use parameters in the prefetched URL that are
>> not needed when navigating to the actual link (e.g. the source of the link
>> click). The server can customize behavior using these parameters without
>> causing a cache miss in the browser.
>> "expects_no_vary_search" addition to Speculation Rules allows the browser
>> to completely handle the case where the user navigates to a URL that is
>> currently prefetched by waiting for the ongoing prefetch instead of
>> directly requesting the page from the server.
>> Google Search conducted experiments prefetching Search results pages from
>> the search box and other links that lead to another Search results page.
>> There was significant latency improvement for navigating to Search result
>> pages prefetched using No-Vary-Search header and "expects_no_vary_search".
>>
>> *Other signals*: No-Vary-Search header has been discussed, together with
>> No-Vary-Search Hint for Prefetch Speculation Rules at Web

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Daniel Bratell]

LGTM2

/Daniel

On 2023-11-07 01:57, Mike Taylor wrote:


Thanks Liviu.

I've spent some time today reviewing the explainer and spec, and find 
the use cases compelling.


LGTM1 to ship. A non-blocking request would be to add the security & 
privacy considerations from the explainer into the draft WICG spec (or 
something similar).


(Also, kudos to all who contributed to the explainer - it's very 
thorough and answered every question I had as I began to review in 
depth. Excellent work.)


On 11/6/23 5:08 PM, Liviu Tinta wrote:
> Are there any open issues that would result in breaking changes, 
after we ship?


There are 2 open issues related to No-Vary-Search: 
https://github.com/WICG/nav-speculation/labels/no-vary-search. None 
of the open issues requires modifying No-Vary-Search header. We are 
not expecting breaking changes after we ship.


On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:

On 11/1/23 9:59 AM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org
, liviuti...@chromium.org



Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md



Specification

https://wicg.github.io/nav-speculation/no-vary-search.html



Summary

Enables prefetch to match even if URL query parameters change.
The No-Vary-Search HTTP response header declares that some or
all parts of a URL's query can be ignored for cache matching
purposes. It can declare that the order of query parameter keys
should not cause cache misses, that specific query parameters
should not cause cache misses or that only certain known query
parameters should cause cache misses. It could apply to multiple
caches, but this entry refers to support for prefetch cache.


We would like to ship "No-Vary-Search support in navigation
prefetch cache" together with "No-Vary-Search Hint for Prefetch
Speculation Rules"
(https://chromestatus.com/feature/4887338302308352
).


Blink component

Internals>Preload




TAG review

https://github.com/w3ctag/design-reviews/issues/797



TAG review status

Positive.


Chromium Trial Name

NoVarySearchPrefetch


Link to origin trial feedback summary

https://github.com/WICG/nav-speculation/issues


Are there any open issues that would result in breaking changes,
after we ship?



Origin Trial documentation link

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193



Risks



Interoperability and Compatibility



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/717
)

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/106
)

/Web developers/: Google Search has been experimenting with
No-Vary-Search header / Speculation Rules
"expects_no_vary_search". This functionality helps Google Search
to match prefetched content to the next user navigation.
Developers can use parameters in the prefetched URL that are not
needed when navigating to the actual link (e.g. the source of
the link click). The server can customize behavior using these
parameters without causing a cache miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows
the browser to completely handle the case where the user
navigates to a URL that is currently prefetched by waiting for
the ongoing prefetch instead of directly requesting the page
from the server.
Google Search conducted experiments prefetching Search results
pages from the search box and other links that lead to another
Search results page. There was significant latency improvement
for navigating to Search result pages prefetched using
No-Vary-Search header and "expects_no_vary_search".

/Other signals/: No-Vary-Search header has been discussed,
together with No-Vary-Search Hint for Prefetch Speculation
Rules at Web Perf WG meeting at TPAC 2023

.



Ergonomics

No-Vary-Search will be used in tandem with Speculation Ru

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Mike Taylor]

Thanks Liviu.

I've spent some time today reviewing the explainer and spec, and find 
the use cases compelling.


LGTM1 to ship. A non-blocking request would be to add the security & 
privacy considerations from the explainer into the draft WICG spec (or 
something similar).


(Also, kudos to all who contributed to the explainer - it's very 
thorough and answered every question I had as I began to review in 
depth. Excellent work.)


On 11/6/23 5:08 PM, Liviu Tinta wrote:
> Are there any open issues that would result in breaking changes, 
after we ship?


There are 2 open issues related to No-Vary-Search: 
https://github.com/WICG/nav-speculation/labels/no-vary-search. None of 
the open issues requires modifying No-Vary-Search header. We are not 
expecting breaking changes after we ship.


On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:

On 11/1/23 9:59 AM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org
, liviuti...@chromium.org



Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md



Specification

https://wicg.github.io/nav-speculation/no-vary-search.html



Summary

Enables prefetch to match even if URL query parameters change.
The No-Vary-Search HTTP response header declares that some or all
parts of a URL's query can be ignored for cache matching
purposes. It can declare that the order of query parameter keys
should not cause cache misses, that specific query parameters
should not cause cache misses or that only certain known query
parameters should cause cache misses. It could apply to multiple
caches, but this entry refers to support for prefetch cache.


We would like to ship "No-Vary-Search support in navigation
prefetch cache" together with "No-Vary-Search Hint for Prefetch
Speculation Rules"
(https://chromestatus.com/feature/4887338302308352
).


Blink component

Internals>Preload




TAG review

https://github.com/w3ctag/design-reviews/issues/797



TAG review status

Positive.


Chromium Trial Name

NoVarySearchPrefetch


Link to origin trial feedback summary

https://github.com/WICG/nav-speculation/issues


Are there any open issues that would result in breaking changes,
after we ship?



Origin Trial documentation link

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193



Risks



Interoperability and Compatibility



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/717
)

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/106
)

/Web developers/: Google Search has been experimenting with
No-Vary-Search header / Speculation Rules
"expects_no_vary_search". This functionality helps Google Search
to match prefetched content to the next user navigation.
Developers can use parameters in the prefetched URL that are not
needed when navigating to the actual link (e.g. the source of the
link click). The server can customize behavior using these
parameters without causing a cache miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows the
browser to completely handle the case where the user navigates to
a URL that is currently prefetched by waiting for the ongoing
prefetch instead of directly requesting the page from the server.
Google Search conducted experiments prefetching Search results
pages from the search box and other links that lead to another
Search results page. There was significant latency improvement
for navigating to Search result pages prefetched using
No-Vary-Search header and "expects_no_vary_search".

/Other signals/: No-Vary-Search header has been discussed,
together with No-Vary-Search Hint for Prefetch Speculation
Rules at Web Perf WG meeting at TPAC 2023

.



Ergonomics

No-Vary-Search will be used in tandem with Speculation Rules
(https://wicg.github.io/nav-speculation/speculation-ru

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Liviu Tinta]

> Are there any open issues that would result in breaking changes, after we 
ship?

There are 2 open issues related to 
No-Vary-Search: https://github.com/WICG/nav-speculation/labels/no-vary-search. 
None of the open issues requires modifying No-Vary-Search header. We are 
not expecting breaking changes after we ship.

On Monday, November 6, 2023 at 1:43:06 PM UTC-5 Mike Taylor wrote:

> On 11/1/23 9:59 AM, Liviu Tinta wrote:
>
> Contact emails dome...@chromium.org, jbro...@chromium.org, 
> liviuti...@chromium.org
>
> Explainer 
> https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
>
> Specification https://wicg.github.io/nav-speculation/no-vary-search.html
>
> Summary 
>
> Enables prefetch to match even if URL query parameters change. The 
> No-Vary-Search HTTP response header declares that some or all parts of a 
> URL's query can be ignored for cache matching purposes. It can declare that 
> the order of query parameter keys should not cause cache misses, that 
> specific query parameters should not cause cache misses or that only 
> certain known query parameters should cause cache misses. It could apply to 
> multiple caches, but this entry refers to support for prefetch cache.
>
> We would like to ship "No-Vary-Search support in navigation prefetch cache" 
> together with "No-Vary-Search Hint for Prefetch Speculation Rules" (
> https://chromestatus.com/feature/4887338302308352).
>
> Blink component Internals>Preload 
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/797
>
> TAG review status Positive.
>
> Chromium Trial Name NoVarySearchPrefetch
>
> Link to origin trial feedback summary 
> https://github.com/WICG/nav-speculation/issues
>
> Are there any open issues that would result in breaking changes, after we 
> ship?
>
>
> Origin Trial documentation link 
> https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/717)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/106)
>
> *Web developers*: Google Search has been experimenting with No-Vary-Search 
> header / Speculation Rules "expects_no_vary_search". This functionality 
> helps Google Search to match prefetched content to the next user 
> navigation. Developers can use parameters in the prefetched URL that are 
> not needed when navigating to the actual link (e.g. the source of the link 
> click). The server can customize behavior using these parameters without 
> causing a cache miss in the browser.
> "expects_no_vary_search" addition to Speculation Rules allows the browser 
> to completely handle the case where the user navigates to a URL that is 
> currently prefetched by waiting for the ongoing prefetch instead of 
> directly requesting the page from the server.
> Google Search conducted experiments prefetching Search results pages from 
> the search box and other links that lead to another Search results page. 
> There was significant latency improvement for navigating to Search result 
> pages prefetched using No-Vary-Search header and "expects_no_vary_search".
>
> *Other signals*: No-Vary-Search header has been discussed, together with 
> No-Vary-Search Hint for Prefetch Speculation Rules at Web Perf WG meeting 
> at TPAC 2023 
> 
> . 
>
> Ergonomics 
>
> No-Vary-Search will be used in tandem with Speculation Rules (
> https://wicg.github.io/nav-speculation/speculation-rules.html). The 
> default usage of No-Vary-Search will not make it hard for Chrome to 
> maintain good performance. 
>
>
> Activation 
>
> It will not be challenging for developers to take advantage of this 
> feature immediately.
>
>
> Security 
>
> See: 
> https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md
>
>
> WebView application risks 
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability 
>
> The website owner can debug the feature in DevTools by making sure that, 
> when navigating to a prefetched page by using a URL that matches under 
> No-Vary-Search conditions, the navigation happens from the prefetch cache 
> by looking at the Size column in the Network tab. In case of success, when 
> hovering over the Size column in the Network tab of Dev Tools, they should 
> see: "Served from prefetch cache, resource size: yyyB". 
>
> No-Vary-Search header value for the prefetch is available on the Network 
> tab. Developers can also use the preloading panel (
> https://crbug.com/1361483) which shows all ongoing preloads.
>
>
> Will this feature be supported on all six Blink platforms (Windows,

Re: [blink-dev] Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Mike Taylor]

On 11/1/23 9:59 AM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md


Specification

https://wicg.github.io/nav-speculation/no-vary-search.html


Summary

Enables prefetch to match even if URL query parameters change. The 
No-Vary-Search HTTP response header declares that some or all parts of 
a URL's query can be ignored for cache matching purposes. It can 
declare that the order of query parameter keys should not cause cache 
misses, that specific query parameters should not cause cache misses 
or that only certain known query parameters should cause cache misses. 
It could apply to multiple caches, but this entry refers to support 
for prefetch cache.



We would like to ship "No-Vary-Search support in navigation prefetch 
cache" together with "No-Vary-Search Hint for Prefetch Speculation 
Rules" (https://chromestatus.com/feature/4887338302308352).



Blink component

Internals>Preload 




TAG review

https://github.com/w3ctag/design-reviews/issues/797


TAG review status

Positive.


Chromium Trial Name

NoVarySearchPrefetch


Link to origin trial feedback summary

https://github.com/WICG/nav-speculation/issues
Are there any open issues that would result in breaking changes, after 
we ship?



Origin Trial documentation link

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193


Risks



Interoperability and Compatibility



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/717)


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/106)


/Web developers/: Google Search has been experimenting with 
No-Vary-Search header / Speculation Rules "expects_no_vary_search". 
This functionality helps Google Search to match prefetched content to 
the next user navigation. Developers can use parameters in the 
prefetched URL that are not needed when navigating to the actual link 
(e.g. the source of the link click). The server can customize behavior 
using these parameters without causing a cache miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows the 
browser to completely handle the case where the user navigates to a 
URL that is currently prefetched by waiting for the ongoing prefetch 
instead of directly requesting the page from the server.
Google Search conducted experiments prefetching Search results pages 
from the search box and other links that lead to another Search 
results page. There was significant latency improvement for navigating 
to Search result pages prefetched using No-Vary-Search header and 
"expects_no_vary_search".


/Other signals/: No-Vary-Search header has been discussed, together 
with No-Vary-Search Hint for Prefetch Speculation Rules at Web Perf WG 
meeting at TPAC 2023 
. 




Ergonomics

No-Vary-Search will be used in tandem with Speculation Rules 
(https://wicg.github.io/nav-speculation/speculation-rules.html). The 
default usage of No-Vary-Search will not make it hard for Chrome to 
maintain good performance.




Activation

It will not be challenging for developers to take advantage of this 
feature immediately.




Security

See: 
https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md




WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?


None



Debuggability

The website owner can debug the feature in DevTools by making sure 
that, when navigating to a prefetched page by using a URL that matches 
under No-Vary-Search conditions, the navigation happens from the 
prefetch cache by looking at the Size column in the Network tab. In 
case of success, when hovering over the Size column in the Network tab 
of Dev Tools, they should see: "Served from prefetch cache, resource 
size: yyyB".


No-Vary-Search header value for the prefetch is available on the 
Network tab. Developers can also use the preloading panel 
(https://crbug.com/1361483) which shows all ongoing preloads.




Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/speculation-rules/prefetch/no-vary-search?label=experimental&label=master&aligned