Missing Origin header when requests to the same-origin and crossorigin set
Categories
(Core :: DOM: Networking, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: me, Assigned: CuveeHsu)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce: The "Origin" header is missing when requesting resources to the same-origin, even though the "crossorigin" attribute is set. In my testing, Firefox was the only browser to exhibit this behavior. All others send the header regardless of domain. Switching between "anonymous" and "use-credentials", did not rectify the issue. Example: <!--[http://1.com/index.html]--> <html> <body> <!--[origin header is sent]--> <script src="http://2.com/script" crossorigin="anonymous"></script> </body> </html> <!--[http://2.com/index.html]--> <html> <body> <!--[origin header is not sent]--> <script src="http://2.com/script" crossorigin="anonymous"></script> </body> </html> Actual results: Origin header is not sent to the server. Expected results: Origin header should be sent to the server.
I can confirm this bug, I'm now experiencing problems with Atlassian Confluence due to lack of Origin header for the same origin.
Comment 2•7 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=446344#c77 says Francois hopes to get to it this quarter. Ben, why'd you make this depend on bug 446344 and not make it a dupe?
Comment 3•7 years ago
|
||
Another bug was handled like that, but it could probably be a dupe.
Comment 4•7 years ago
|
||
OK, if precedent exists let's leave this depending upon bug 446344. Thanks :)
Comment 5•5 years ago
|
||
I suspect this is https://github.com/whatwg/fetch/issues/871 in part (there other browsers are also not sending the header though).
Updated•5 years ago
|
Comment 6•4 years ago
|
||
Per https://github.com/web-platform-tests/wpt/pull/22567 browsers do not send the Origin header for CORS same-origin GET, but we do fail a couple of cases there we should probably fix.
Assignee | ||
Comment 7•4 years ago
|
||
Thanks. Will fix when the change in wpt is merged to central.
Assignee | ||
Comment 8•4 years ago
|
||
(In reply to Anne (:annevk) from comment #6)
Per https://github.com/web-platform-tests/wpt/pull/22567 browsers do not send the Origin header for CORS same-origin GET, but we do fail a couple of cases there we should probably fix.
Sorry for a late weighing in.
The only additional failure is
"Origin header and POST same-origin fetch cors mode with Referrer-Policy no-referrer"
"assert_equals: expected "null" but got "http://web-platform.test:8000"
However the change which fails us isn't about the GET/CORS combination
https://searchfox.org/mozilla-central/diff/a435a8c59595dad833c7368912ea9c2dfbbf948b/testing/web-platform/tests/fetch/origin/assorted.window.js#197-198
We can translate the test to:
if mode == cors && it's a cross-origin fetch ==> ignore the referrer-policy
but the spec change is stopped (and possible not match the test) https://github.com/whatwg/fetch/pull/1013
What do you think, Anne?
Do you think it's a right move? Or we need to ask the rationale?
Comment 9•4 years ago
|
||
The current specification at https://fetch.spec.whatwg.org/#append-a-request-origin-header does not look at whether the request's mode is "cors", it looks at whether request's response tainting is "cors". For that to happen a request with mode "cors" would have had to go through a cross-origin URL at some point. So in the same-origin case the otherwise branch kicks in here. Hope that helps.
Assignee | ||
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
Pushed by juhsu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a925b80f029e don't take Referrer-Policy into account when response tainting is cors, r=valentin
Comment 12•4 years ago
|
||
bugherder |
Comment 13•4 years ago
|
||
This fix causes a regression that results in Origin: null
for same-origin requests with Referrer-Policy: no-referrer
. See bug 1632204.
Description
•