> Now, when it looks like this will be shipped, can you please update the stalled standard-position issues for Mozilla and WebKit so that they know that we'll proceed with it. The standard position issues for both Mozilla and WebKit were updated.
On Wednesday, June 12, 2024 at 7:42:05 AM UTC-4 Daniel Bratell wrote: > Now, when it looks like this will be shipped, can you please update the > stalled standard-position issues for Mozilla and WebKit so that they know > that we'll proceed with it. > > /Daniel > On 2024-06-06 19:21, Vladimir Levin wrote: > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NtUdUeqkT%3DyhKJMgUw3RDc1kb7Vts3kz_6GJyCnAMKnw%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/433da03b-061a-4a4d-a002-26b2e2c092d6n%40chromium.org.
