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.
On Fri, Nov 10, 2023 at 2:49 PM 'David Schinazi' via blink-dev < blink-dev@chromium.org> wrote: > 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 > <https://www.iana.org/assignments/http-fields/http-fields.xhtml>, 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 > > > On Fri, Nov 10, 2023 at 12:34 PM Yoav Weiss <yoavwe...@chromium.org> > wrote: > >> 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. >> >> On Fri, Nov 10, 2023 at 9:44 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> >>> >>> 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/CAHwtu-GK%3DH%2BzR41p3vOvQ-poUje56VJ1jzSAfHaJhne-iRU-jg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHwtu-GK%3DH%2BzR41p3vOvQ-poUje56VJ1jzSAfHaJhne-iRU-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/CAF8qwaCDAya1P6VmkfQpM%3D1fvxXMB3Koptd8-Ktd5CoKZZEw1A%40mail.gmail.com.
