Intent to Ship: Modulepreload Referrer Header Fix
Chromestatus
Contact emails
hjanu...@gmail.comExplainer
NoneSpecification
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload:script-fetch-optionsSummary
Fixes modulepreload to properly send referrer headers by using ClientReferrerString() instead of NoReferrer(). This aligns Chrome with the HTML specification which requires using the client's referrer for module fetches. Includes WPT test verifying both dynamic imports and modulepreload correctly send referrer headers.
Blink component
Blink>Loader>PreloadTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
The primary risk is that some servers may have adapted to Chrome's non-standard behavior, implementing logic that assumes modulepreload requests will never include referrer headers. These systems could potentially mishandle or reject requests with the newly added referrer information. However, this risk is mitigated by the fact that other major browsers already implement the correct behavior, meaning most cross-browser web applications should already handle referrer headers properly. Additionally, since modulepreload is a relatively recent feature, widespread dependence on the incorrect behavior is unlikely. The benefit of standards compliance and consistent behavior across script loading methods outweighs these potential compatibility concerns.
Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
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)?
NoIs this feature fully tested by web-platform-tests?
NoFlag name on about://flags
NoneFinch feature name
NoneNon-finch justification
NoneRollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://crbug.com/409959472Estimated 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).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144463990849536?gate=4969922291302400
Domenic Denicola
Contact emails
hjanu...@gmail.comExplainer
NoneSpecification
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload:script-fetch-optionsSummary
Fixes modulepreload to properly send referrer headers by using ClientReferrerString() instead of NoReferrer(). This aligns Chrome with the HTML specification which requires using the client's referrer for module fetches. Includes WPT test verifying both dynamic imports and modulepreload correctly send referrer headers.
Blink component
Blink>Loader>PreloadTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
The primary risk is that some servers may have adapted to Chrome's non-standard behavior, implementing logic that assumes modulepreload requests will never include referrer headers. These systems could potentially mishandle or reject requests with the newly added referrer information. However, this risk is mitigated by the fact that other major browsers already implement the correct behavior, meaning most cross-browser web applications should already handle referrer headers properly. Additionally, since modulepreload is a relatively recent feature, widespread dependence on the incorrect behavior is unlikely. The benefit of standards compliance and consistent behavior across script loading methods outweighs these potential compatibility concerns.
Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
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)?
NoIs this feature fully tested by web-platform-tests?
No
Flag name on about://flags
NoneFinch feature name
NoneNon-finch justification
None
Rollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://crbug.com/409959472Estimated 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).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144463990849536?gate=4969922291302400This intent message was generated by Chrome Platform Status.
--
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/6823a747.050a0220.624fd.01b3.GAE%40google.com.
