Intent to Ship: No-Vary-Search support in navigation prefetch cache

[Liviu Tinta]

Contact emails

dom...@chromium.org, jbr...@chromium.org, liviu...@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

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

Flag name on chrome://flags

Finch feature name

NoVarySearchPrefetch

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1378075

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Estimated milestones

Shipping on desktop	121
OriginTrial desktop last	120
OriginTrial desktop first	110
DevTrial on desktop	110

Shipping on Android	121
OriginTrial Android last	120
OriginTrial Android first	110
DevTrial on Android	110

Shipping on WebView	121
OriginTrial webView last	120
OriginTrial webView first	110

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5071247189213184

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKutrvgMxR%3DnfAQOfBHNJo9ifrmFRSbiE0heDyeW0uKJA%40mail.gmail.com 

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYLGT%2BV3_u_oumjHCZD05RRYY5guMjz1vb7501sNF1CANg%40mail.gmail.com
Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/7oMlGWmVv2Q/m/B2PACBSnBgAJ

[Mike Taylor]

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

Contact emails

dom...@chromium.org, jbr...@chromium.org, liviu...@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?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKL2psmkYpQQ6KjrM_41yt8f%3DvH_-m0%3DT4idWT4zSumHw%40mail.gmail.com.

[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

dom...@chromium.org, jbroman@chromium.org, liviutinta@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

[Daniel Bratell]

LGTM2

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b878e749-5d1a-4205-8612-3bd36db82fb3%40chromium.org.

[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 <brat...@gmail.com> 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

dom...@chromium.org, jbr...@chromium.org, liviu...@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKL2psmkYpQQ6KjrM_41yt8f%3DvH_-m0%3DT4idWT4zSumHw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b878e749-5d1a-4205-8612-3bd36db82fb3%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/265d9c2a-08fc-4ee8-b1ec-f125a910c91f%40gmail.com.

[Domenic Denicola]

On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss <yoav...@chromium.org> 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!

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVT%2BDdvQL0hxDM9SW2PkfC7c%3DSw3FB6CC0a%2BSrseNT-Jg%40mail.gmail.com.

[Yoav Weiss]

On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola <dom...@chromium.org> wrote:

On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss <yoav...@chromium.org> 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. 

[Domenic Denicola]

2023年11月10日(金) 17:14 Yoav Weiss <yoav...@chromium.org>:

On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola <dom...@chromium.org> wrote:

On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss <yoav...@chromium.org> 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!

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

[David Schinazi]

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHwtu-GK%3DH%2BzR41p3vOvQ-poUje56VJ1jzSAfHaJhne-iRU-jg%40mail.gmail.com.