New issue
Advanced search Search tips
Starred by 11 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Mar 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Preflight CORS requests include Origin and Accept in Access-Control-Request-Headers

Reported by, Dec 22 2011

Issue description

Chrome Version       : 16.0.912.63
OS Version: OS X 10.7.2
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
    FF 8.0: OK

What steps will reproduce the problem?
1. Use XMLHttpRequest to send a non-simple POST (e.g. content-type application/json)
2. Observe headers (pasted below)

What is the expected result?

In this case, the only header that should be in Access-Control-Request-Headers is Content-Type. Not Origin, and not Accept.

Here's a paste of the view from the Developer Tools of this going wrong.

Request URL:http://localhost:15000/r4dws/services/doc/processText
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Access-Control-Request-Headers:Origin, Content-Type, Accept
Response Headersview source
Access-Control-Allow-Headers:Origin, Content-Type, Accept
Date:Thu, 22 Dec 2011 02:15:36 GMT

What happens instead?

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7


Comment 1 by, Dec 22 2011

Labels: -Area-Undefined Area-Internals Internals-Network-HTTP

Comment 2 by, Jan 27 2012

Labels: Area-WebKit
Pretty sure these headers are handled WebKit-side, rather than by Chrome's network stack.
Project Member

Comment 3 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network-HTTP -Area-WebKit Cr-Content Cr-Internals-Network-HTTP Cr-Internals

I just wanted to offer some more testing and context on this issue, for anyone who comes later. I apologize if I'm just going over the basics for crowd here.

What's the bug? The bug is that when a JavaScript XMLHttpRequest requests a POST request (for instance), and the browser automatically generates the CORS preflight OPTIONS request, the browser inserts additional values into the preflight request's Access-Control-Request-Headers header.

In particular, I am seeing that Chrome is adding the "origin" header unnecessarily.

The CORS spec ( ) in section 7.1.5, describes what's supposed to be in Access-Control-Request-Headers: "If author request headers is not empty include an Access-Control-Request-Headers header with as header field value a comma-separated list of the header field names from author request headers in lexicographical order, each converted to ASCII lowercase (even when one or more are a simple header)."

So Access-Control-Request-Headers is only supposed to include "author request headers". What are they? Is "Origin" one of them?  No. We know this because elsewhere, (sec 7.1) the spec describes "author request headers" as the headers "set by the authors for the request". Section 4.6.2 of the XMLHttpRequest spec ( ), and section 4.7.2 of the XMLHttpRequest2 spec ( ), both imply the author request headers are those headers explicitly set via the XMLHttpRequest#setRequestHeader method, and both specs specifically exclude a list of standard headers -- including "Origin"! -- from being set by this method.

This bug is present in Chrome 25.0.1364.172 and Safari Version 6.0.3 (8536.28.10) but not Firefox 19.0.2, so presumably this is a webkit issue.

I am attaching screenshots that show the http traffic in all three browsers, and highlight where you can see the evidence of "origin" being passed.
1.3 MB Download
Belatedly realized this is a known-issue on webkit's bug tracker:

Comment 6 by, Mar 26 2013

Blockedon: webkit:63460
Labels: Cr-Content-Core
Does indeed sound like a WebKit issue.  WebKit is responsible for most (Possibly all) CORS behavior.

Looks like that bug hasn't been updated in about 1 and a half years, so don't think a fix is likely any time soon.
Yes. On the other hand, the CORS spec was substantially revised since then, clarifying this issue of which request headers to include. That WebKit bug tracker discussion was following the 2010 spec, and its ambiguity regarding headers stymied agreement on the fix.

The 2012 spec introduces the term "author request fields", which seems to clarify the issue by referring to that same term as it is more or less exactly defined in the xmlhttlrequest spec.

So maybe now the time is ripe.

Also, it's worth noting that the behavior seems to have improved from she this issue was originally reported, since the "accept" field is not being added.
+1 shocking that this has not been addressed. Nobody cares if the fix is a chrome or webkit team responsibility - get it fixed people! 
Project Member

Comment 9 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
The issue of 'origin' being passed in Access-Control-Request-Headers header is resolved with
Labels: -OS-Mac -Cr-Internals -Cr-Content-Core -Cr-Blink OS-All Cr-Blink-XHR
Checking the current behavior (40.0.2214.115)

Send a POST xhr with setting content-type from to http://localhost

>>> preflight request
Remote Address:
Request URL:http://localhost/
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept-Encoding:gzip, deflate, sdch
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

>>> preflight response
Response Headersview source
Date:Wed, 04 Mar 2015 04:35:00 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.7 (Ubuntu)
Blockedon: -webkit:63460
Status: Fixed
It seems the reported issue was fixed, although I don't know when.

Comment 14 by, Nov 27 2015

Labels: -Cr-Blink-XHR Cr-Blink-Network-XHR
Components: Internals>Network
Components: -Internals>Network>HTTP

Sign in to add a comment