Closed Bug 1341689 Opened 8 years ago Closed 5 years ago

Missing Origin header when requests to the same-origin and crossorigin set

Categories

(Core :: DOM: Networking, defect, P2)

Product:
Core
Component:
DOM: Networking
Version:
54 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla77
Tracking Flags:
Tracking Status
firefox77 --- fixed

People

(Reporter: me, Assigned: CuveeHsu)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Bug 1341689 - don't take Referrer-Policy into account when response tainting is cors, r=valentin
47 bytes, text/x-phabricator-request
Details | Review
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.
Summary: Origin header is missing when requesting resources to the same-origin with crossorigin set → Origin header is missing when requesting resources to the same-origin then crossorigin is set
Summary: Origin header is missing when requesting resources to the same-origin then crossorigin is set → Missing Origin header when requests to the same-origin and crossorigin set
Component: Untriaged → DOM
Product: Firefox → Core
I can confirm this bug, I'm now experiencing problems with Atlassian Confluence due to lack of Origin header for the same origin.
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?
Flags: needinfo?(bkelly)
Priority: -- → P2
Another bug was handled like that, but it could probably be a dupe.
Flags: needinfo?(bkelly)
OK, if precedent exists let's leave this depending upon bug 446344. Thanks :)
Depends on: 1424076

I suspect this is https://github.com/whatwg/fetch/issues/871 in part (there other browsers are also not sending the header though).

Component: DOM → DOM: Core & HTML

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.

Component: DOM: Core & HTML → DOM: Networking
Flags: needinfo?(juhsu)
Priority: P2 → --

Thanks. Will fix when the change in wpt is merged to central.

Assignee: nobody → juhsu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(juhsu)
Priority: -- → P2
Whiteboard: [necko-triaged]

(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?

Flags: needinfo?(annevk)

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.

Flags: needinfo?(annevk)
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

https://hg.mozilla.org/mozilla-central/rev/a925b80f029e

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox77: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

This fix causes a regression that results in Origin: null for same-origin requests with Referrer-Policy: no-referrer. See bug 1632204.

Regressions: 1632204
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: