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.
