New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 621712 link

Starred by 14 users
Status: Duplicate
Merged: issue 621788
Owner: ----
Closed: Jun 2016
Cc:
jochen@chromium.org
█ mkwst@chromium.org
█ tyoshino@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Origin header is not set on requests

Reported by key...@lucidchart.com, Jun 20 2016 
UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8459.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2768.0 Safari/537.36
Platform: 8459.0.0 (Official Build) dev-channel samus

Example URL:

Steps to reproduce the problem:
var xhr = new XMLHttpRequest;
xhr.open('GET', 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS');
xhr.send();

Open the network tab of the dev tools, and look at the request headers.

What is the expected behavior?
There is an Origin header.

What went wrong?
There is not an Origin header.

Did this work before? Yes It works on Chrome 51

Chrome version: 53.0.2768.0  Channel: dev
OS Version: 8459.0.0
Flash Version: Shockwave Flash 22.0 r0

An Origin header is needed and often used.

For example, if a resource should be given to a.com and b.com origins, the server will be configured to set 'Access-Control-Allow-Origin: *' if the request Origin is a.com or b.com.

Without the browser sending an Origin header, this cannot happen.

Comment 1 by davidben@chromium.org, Jun 21 2016

Cc: tyoshino@chromium.org mkwst@chromium.org jochen@chromium.org
My understanding is this is all kind of a mess right now, even in the specs.
https://github.com/whatwg/xhr/issues/31

From that link and the linked fetch issue, one of +tyoshino, jochen, mkwst might have a better idea of what's going on here.

Comment 2 by davidben@chromium.org, Jun 21 2016

Components: Blink>Network>XHR

Comment 3 by tyoshino@chromium.org, Jun 22 2016 

As discussed in the issue pasted by davidben@, Chromium is violating the current spec in the point that Chromium doesn't send the Origin header for same-origin GET and POST requests. But this behavior shouldn't be different between Chrome 53 and 51. On what origin did you run the code? On https://developer.mozilla.org/ ?

Comment 4 by mmenke@chromium.org, Jun 23 2016

Components: -Internals>Network Blink>SecurityFeature
Removing the network label - this is all handled in blink.

Comment 5 by paulddra...@gmail.com, Jun 23 2016 

This is happening on CORS requests. Though we can only reproduce it on www.lucidchart.com and www.lucidpress.com origins.

Several customers have reported this.

Comment 6 by tyoshino@chromium.org, Jun 24 2016 

Can you try the latest canary?

This might be due to  bug 620746

Comment 7 by key...@lucidchart.com, Jun 24 2016 

This appears to be fixed. 

I confirmed that Canary fixes the issue on a Mac which exhibits this behavior in Chrome Dev, though I am unable to confirm the fix on the original machine that experienced this (since Chromium is not available on a Chromebook Pixel).

Thanks for the fix!

Comment 8 by mmenke@chromium.org, Jun 24 2016

Mergedinto: 621788
Status: Duplicate (was: Unconfirmed)
Thanks for the followup!  Going to mark this as a dupe of the fixed bug.
►

Sign in to add a comment