Intent to Ship: Stop sending Purpose: prefetch header from prefetches and prerenders

[Chromestatus]

Contact emails

stev...@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

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?

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.

[Yoav Weiss (@Shopify)]

Do y'all have any estimate on potential breakage, what may be its scale and what it may look like?

[Domenic Denicola]

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. (Here's an attempt 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.

[Yoav Weiss (@Shopify)]

LGTM1 for a slow roll-out, given the fact that "breakage" may most likely present itself as extra server load.

[Daniel Bratell]

LGTM2

/Daniel

--
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+...@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.

[Chris Harrelson]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3aa765b6-0b41-438f-978d-64658d6a0522%40gmail.com.