LGTM1 for a slow roll-out, given the fact that "breakage" may most likely present itself as extra server load.
On Tue, Jul 1, 2025 at 5:42 AM Domenic Denicola <dome...@google.com> wrote: > We're optimistic that this will result in no "breakage". The Purpose > header was not reliable (e.g., it was Chromium only, and it was only sent > by some types of preloads). Sec-Purpose has been in place for a long time > now, and is the one documented everywhere, that works in Firefox, etc. > > That said, it's hard to get visibility into what server operators are > doing with headers. Probably the most common use would be denying some > preload traffic. In that case, removing it might cause the server to > perform more serving operations than they previously did, if the server is > not also checking Sec-Purpose. But in the theoretical worst case, the > server could be varying its content on the header, which would result in > users seeing different responses. (This seems very unlikely, as sending > different responses for preloads vs. normal loads is a very bad idea in the > first place.) > > We've generally found that most open-source code checks a large variety of > headers, including the standard Sec-Purpose, and so won't be affected. See, > e.g., some of the results from this GitHub code search > <https://github.com/search?q=Sec-Purpose+prefetch+language%3AJava+&type=code>. > (Here's an attempt > <https://github.com/search?q=prefetch+AND+%5C%22Purpose%5C%22+AND+NOT+Sec-Purpose+language%3AJava+&type=code&p=4> > at > the inverse code search, which doesn't show any cases of only checking for > Purpose, but I'm not sure the search is very well-crafted.) Unfortunately > this isn't something we can use-count, so I think the best approach here is > to just roll it out and be prepared to kill-switch if something unexpected > shows up. > > On Tue, Jul 1, 2025 at 12:45 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> Do y'all have any estimate on potential breakage, what may be its scale >> and what it may look like? >> >> On Thursday, June 26, 2025 at 8:43:52 PM UTC+2 Chromestatus wrote: >> >>> Contact emails steven...@microsoft.com >>> >>> Explainer https://github.com/whatwg/fetch/pull/1576 >>> >>> Specification >>> https://wicg.github.io/nav-speculation/prerendering.html#interaction-with-fetch >>> >>> Design docs >>> https://fetch.spec.whatwg.org/#ref-for-http-sec-purpose%E2%91%A0 >>> >>> https://wicg.github.io/nav-speculation/prefetch.html#ref-for-http-sec-purpose >>> >>> Summary >>> >>> Now that prefetches and prerenders are utilizing the Sec-Purpose header >>> for prefetches and prerenders, we will move to remove the legacy Purpose: >>> prefetch header that is still currently passed. This will be behind a >>> feature flag/ kill switch to prevent compat issues. This will be scoped to >>> speculation rules prefetch, speculation rules prerender, <link >>> rel=prefetch>, and Chromium's non-standard <link rel=prerender>. >>> >>> >>> Blink component Blink>Loader >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%22> >>> >>> TAG review Not filed as this is a minor change of unspec'ed UA behavior >>> for an existing feature. (Can start a review if recommended) >>> >>> TAG review status Not applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> As commented at notes on Firefox and Safari, each browser uses >>> non-standardized header name that is not aligned with CORS spec. This >>> change will introduce better interoperability and compatibility for a long >>> term. >>> >>> >>> *Gecko*: Positive ( >>> https://github.com/mozilla/standards-positions/issues/1259) >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1965945 They currently >>> already pass the web platform tests for standardizing on using Sec-Purpose >>> for prefetch. >>> >>> *WebKit*: Support ( >>> https://github.com/WebKit/standards-positions/issues/114) Positive as >>> part of aligning on <link rel=prefetch> >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> 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 >>> >>> None >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? Yes >>> >>> Yes, since it affects <link rel=prefetch> which is on all platforms >>> >>> >>> 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/preload/prefetch-headers.https.html?label=experimental&label=master&aligned >>> >>> >>> Flag name on about://flags None >>> >>> Finch feature name RemovePurposeHeaderForPrefetch >>> >>> Rollout plan Will ship enabled for all users >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://issues.chromium.org/issues/420724819 >>> >>> Estimated milestones >>> Shipping on desktop 139 >>> Shipping on Android 139 >>> Shipping on WebView 139 >>> >>> 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/5088012836536320?gate=5120193717862400 >>> >>> Links to previous Intent discussions Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6836470b.2b0a0220.33c819.0963.GAE%40google.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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKKakt%2Bk%2BePB209anKsh9Mzar-PjLDvChJC_K8kLrQ5Hw%40mail.gmail.com.
