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/CAM0wra-p72SSnhRDshWorjA-fNJB5cCa-V%3D%2Bwy3FDM4jDzO%2BAg%40mail.gmail.com.
