LGTM1 - I'm very happy to see this ship.
On 6/6/24 11:42 AM, Domenic Denicola wrote:
I will abstain from approving this feature as an API Owner, as one of
the people responsible for it. But I will urge other API owners to
approve it, and give a bit of reasoning.
In my opinion, this is a straightforward extension from prefetch to
prerender which makes the web platform more uniform. It is good that
it is being done as a separate intent, since it is shipping at a
different time, and thus need to appear separately in e.g. beta blog
posts and other developer-facing documentation. But I think the same
considerations that helped the prefetch version get a prompt approval
should apply here.
BTW, looking back on that previous thread
<https://groups.google.com/a/chromium.org/g/blink-dev/c/XnG5BF3uoeE/m/fwR6LDt4BQAJ>,
some of the non-blocking discussion raised there was about engaging
the HTTPWG. I'm happy to report that we've started this process,
producing a draft RFC
<https://datatracker.ietf.org/doc/draft-wicg-http-no-vary-search/01/> and
getting some discussion
<https://lists.w3.org/Archives/Public/ietf-http-wg/2024JanMar/0110.html>
started on the relevant mailing list, which seem relatively positive
to me. There was also some concern about ensuring that compression
dictionaries and this header aligned on the same naming; as far as I
can tell that issue no longer exists as the latest compression
dictionaries draft
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> only
has "match", and no longer "match-query".
On Wednesday, June 5, 2024 at 11:04:10 PM UTC+9 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#prerendering-activation
<https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#prerendering-activation>
Specification
https://wicg.github.io/nav-speculation/no-vary-search.html
<https://wicg.github.io/nav-speculation/no-vary-search.html>
Summary
Enables a prerender entry 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 prerender.
Blink component
Internals>Preload>Prerender
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload%3EPrerender>
TAG review
https://github.com/w3ctag/design-reviews/issues/797
<https://github.com/w3ctag/design-reviews/issues/797>
TAG review status
Pending
Risks
Interoperability and Compatibility
None
Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/717
<https://github.com/mozilla/standards-positions/issues/717>)
WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/106
<https://github.com/WebKit/standards-positions/issues/106>)
Web developers: No signals Below is the text from the I2S of the
No-Vary-Search on navigational prefetch, and we believe the same
applies to Prerendering. 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.
https://docs.google.com/presentation/u/1/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31
<https://docs.google.com/presentation/u/1/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31>
Ergonomics
(Text taken from Prefetch NVS I2S)
No-Vary-Search will be used in tandem with Speculation Rules
(https://wicg.github.io/nav-speculation/speculation-rules.html
<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
This should be a natural extension to the previous feature launch
"No-Vary-Search support in navigation prefetch cache"
(https://groups.google.com/a/chromium.org/g/blink-dev/c/XnG5BF3uoeE/m/fwR6LDt4BQAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/XnG5BF3uoeE/m/fwR6LDt4BQAJ>)
Before this launch, No-Vary-Search was only respected for
speculation rules targeting prefetch, so web author may have
specified them without knowing that it wouldn't work. With this
launch, No-Vary-Search header will be respected on all types of
Speculation Rule
Sethttps://wicg.github.io/nav-speculation/speculation-rules.html#speculation-rule-set
<https://wicg.github.io/nav-speculation/speculation-rules.html#speculation-rule-set>,
so it is more consistent.
Security
See:https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md
<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?
We are closely working with Android WebView team, and the broader
prerender feature is gated through new AwSettings API (currently
@RequiresOptIn) so there's zero risk that it will break existing
WebView apps.
Debuggability
None
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned
<https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned>
(The test files starting with no-vary-search)
Flag name on chrome://flags
None
Finch feature name
Prerender2NoVarySearch
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/41494389
<https://issues.chromium.org/issues/41494389>
Estimated milestones
Shipping on Desktop
127
Shipping on Android
127
Shipping on WebView
127
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/5099218903760896?gate=5171022636777472
<https://chromestatus.com/feature/5099218903760896?gate=5171022636777472>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqY%2B13miDT4YS3%3DjhgW4V6Cv8FZ3E_QT2Tj6aq1yy%3DJgsyw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqY%2B13miDT4YS3%3DjhgW4V6Cv8FZ3E_QT2Tj6aq1yy%3DJgsyw%40mail.gmail.com>
This intent message was generated by Chrome Platform Status
<https://chromestatus.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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/65609d80-3c17-4853-bae6-e9576cf4582fn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/65609d80-3c17-4853-bae6-e9576cf4582fn%40chromium.org?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6aeadef-3cf7-4397-b936-3031b1092d70%40chromium.org.
