This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current referrer policy hook is the first step of HTTP fetch. I believe this means that the preflight request will have an unmodified referrer header. Is that intentional? It seems wrong. We should probably move the hook somewhere higher up (or just duplicate it for the prefetch, whichever you prefer).
Yeah, the problem is that I don't quite know what the referrer argument to Fetch should be. Currently HTML has a "referrer source" concept which is either a URL or a Document. Fetch gets a Window already (through client) which seems somewhat redundant with the "referrer source" concept so I wonder if we can do some convergence there. However, CORS preflight fetch invokes HTTP fetch to do the preflight so that part seems fine, no?
You're right, pushing the preflight fetch through the HTTP fetch algorithm solves the issue. Sorry I missed that detail. Regarding the 'referrer source' concept, is there any case in which a request can be made with a referrer source other than the JavaScript global environment which generated the request?
Yeah, e.g. style sheets want to use their own URL and not the URL of the environment they're associated with. SVG embedded as image fetching subresources would want to do the same. The SVG WG is notoriously bad at actually defining these things carefully though.
Hrm. Both those cases seem strange.
I have ended up moving the referrer hook higher up by the way. The rationale is that I'd like Request to have a referrer field that service worker can rely on (a header would only be included in network requests). So early on during fetch we'd figure out the referrer and then pass it through CSP for a policy check.
This was improved as part of https://github.com/whatwg/fetch/commit/35b2c8b42797e1b2bc8e97f204aaf7c618599202 and fixed in bug 26058.