Intent to Ship: Pass 'Sec-Purpose: prefetch' header with <link rel=prefetch>

[Chromestatus]

Contact emails

stev...@microsoft.com

Explainer

https://github.com/w3c/resource-hints/issues/74

Specification

https://chromium-review.googlesource.com/c/chromium/src/+/6334746

Summary

Chrome currently passes both 'Purpose: prefetch' and 'Sec-Purpose: prefetch' headers as part of prefetch through speculation rules. However, only 'Purpose: prefetch' is passed with <link rel=prefetch>. We plan to standardize this header for both speculation rules and <link rel=prefetch> by adding 'Sec-Purpose: prefetch' header to the latter. Future work will involve stop sending 'Purpose: prefetch' for prefetches, prerenders, etc.

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

Pending

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: No signal Firefox has sent ‘X-moz: prefetch’.

WebKit: No signal Safari has sent 'Purpose: prefetch' but changed to use 'X-Purpose: preview'.

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

Plan to add a new test.

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40236973

Estimated milestones

No milestones specified

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/6247959677108224?gate=4656924191096832

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/680fb6c9.050a0220.1699c.03f6.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Thu, May 8, 2025 at 11:11 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

stev...@microsoft.com

Explainer

https://github.com/w3c/resource-hints/issues/74

Specification

https://chromium-review.googlesource.com/c/chromium/src/+/6334746

That's not a specification. Is it possible to file an issue on HTML and try to bake that into the standard? 

Summary

Chrome currently passes both 'Purpose: prefetch' and 'Sec-Purpose: prefetch' headers as part of prefetch through speculation rules. However, only 'Purpose: prefetch' is passed with <link rel=prefetch>. We plan to standardize this header for both speculation rules and <link rel=prefetch> by adding 'Sec-Purpose: prefetch' header to the latter. Future work will involve stop sending 'Purpose: prefetch' for prefetches, prerenders, etc.

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

Pending

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: No signal Firefox has sent ‘X-moz: prefetch’.

WebKit: No signal Safari has sent 'Purpose: prefetch' but changed to use 'X-Purpose: preview'.

Can you open vendor position requests and try to get them on board this change?

Also, does Safari support <link rel=prefeftch>? Or is that for URL bar driven prefetches? 

Web developers: No signals

With my web developer hat on, these different headers are definitely a hurdle and can cause some prefetches to be missed.

 

--
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/681d1e1b.050a0220.d6048.0024.GAE%40google.com.

[Steven Wei]

Thanks! Added an issue to whatwg/html repo:  Can we include what header(s) get sent with link type prefetch? · Issue #11294 · whatwg/html
Also, I don't think Safari supports <link rel=prefetch>.

Also, started vendor position requests:
Mozilla: Send Sec-Purpose header for link type prefetch (rel=prefetch) · Issue #1228 · mozilla/standards-positions
Webkit:  Send Sec-Purpose header for link type prefetch (rel=prefetch) · Issue #493 · WebKit/standards-positions

[Steven Wei]

domenic@ found the place in HTML spec that already mentioned this header for prefetch:  Fetch Standard

Positive for Mozilla as they've already mainly migrated to using the header,

and not planned for Webkit and they don't support rel=prefetch.

[Mike Taylor]

Before continuing the review, could you please request all the privacy, security, enterprise, etc bits in the chromestatus entry?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70f2338a-168f-4747-be74-2784fb90f436n%40chromium.org.

[Steven Wei]

Yes, thanks for the reminder. This is my first Intent to Ship so will note this for future ones! 

[Dan Clark]

LGTM1

[Alex Russell]

LGTM2

[Yoav Weiss (@Shopify)]

LGTM3