LGTM3 On Thu, Jun 6, 2024 at 12:45 PM Chris Harrelson <[email protected]> wrote:
> LGTM2 > > On Wed, Jun 5, 2024 at 9:56 PM Mike Taylor <[email protected]> wrote: > >> 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 >> >> [email protected], [email protected], [email protected] >> >> Explainer >> >> 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 >> >> 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 >> >> TAG review status >> >> Pending >> >> Risks >> >> Interoperability and Compatibility >> >> None >> >> >> Gecko: No signal (https://github.com/mozilla/ >> standards-positions/issues/717) >> >> WebKit: No signal (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 >> >> 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). 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 ) >> >> 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 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 >> >> >> >> >> 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 >> >> (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 >> >> 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 >> >> 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 >> >> 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 [email protected]. >> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6aeadef-3cf7-4397-b936-3031b1092d70%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qGedddYf6siEo6HLMaftfjB-0mvj%2BH8%3Dg27LTJM4q_w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qGedddYf6siEo6HLMaftfjB-0mvj%2BH8%3Dg27LTJM4q_w%40mail.gmail.com?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NtUdUeqkT%3DyhKJMgUw3RDc1kb7Vts3kz_6GJyCnAMKnw%40mail.gmail.com.
