2023年11月10日(金) 17:14 Yoav Weiss <yoavwe...@chromium.org>: > > > On Thu, Nov 9, 2023 at 2:46 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Thu, Nov 9, 2023 at 12:44 AM Yoav Weiss <yoavwe...@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 <dschin...@google.com> 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 <pmee...@google.com> and David > are also likely to have contacts and insights. > > >> >>> >>> On Wed, Nov 8, 2023 at 4:20 PM Daniel Bratell <bratel...@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 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> >>>>> >>>>> 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 >>>>> <https://docs.google.com/presentation/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31> >>>>> . >>>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? 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 >>>>> >>>>> -- >>>>> 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/CAHaAqYKL2psmkYpQQ6KjrM_41yt8f%3DvH_-m0%3DT4idWT4zSumHw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKL2psmkYpQQ6KjrM_41yt8f%3DvH_-m0%3DT4idWT4zSumHw%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 blink-dev+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b878e749-5d1a-4205-8612-3bd36db82fb3%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/265d9c2a-08fc-4ee8-b1ec-f125a910c91f%40gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/265d9c2a-08fc-4ee8-b1ec-f125a910c91f%40gmail.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 blink-dev+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVT%2BDdvQL0hxDM9SW2PkfC7c%3DSw3FB6CC0a%2BSrseNT-Jg%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_EQr0pJi-aRNihrgP7fAZ7Rw5qW7imKYhZCEgL-2dtww%40mail.gmail.com.
