Why are non-custom headers included in Access-Control-Request-Headers?

问题

I am trying to send a cross-origin request. As far as the Access-Control-Request-Headers is concerned, I am getting different behavior in FireFox, Chrome and Safari.

Chrome :- Access-Control-Request-Headers:  origin, content-type, accept
Safari :- Access-Control-Request-Headers:  origin, content-type, accept
Firefox:- Access-Control-Request-Headers:  content-type

My questions are :-

1. How do browsers decide which headers will be part of Access-Control-Request-Headers?
2. As far as I know there should only be custom headers in Access-Control-Request-Headers, but all three (accept,origin and content-type) are not custom headers. Then why are they part of Access-Control-Request-Headers?
3. Why does the behavior vary by browser?

回答1:

There are a lot of different things going on here, so I'll answer them one at a time.

Chrome and Safari are both based on WebKit, which is why you are seeing the same behavior in those browsers (Chrome is moving to Blink soon, but that isn't in the hands of users yet).

The latest CORS spec states that Accept is a simple request header. Origin is not included in the list of simple request headers, but it would be silly for it not to be supported since it is the foundation of CORS. So technically Firefox is doing the right thing.

However note that although Chrome/Safari include the Accept and Origin headers, they do not verify that those headers are included in the Access-Control-Allow-Headers response header. You can verify this by visiting the following link:

http://client.cors-api.appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&server_enable=true&server_status=200&server_credentials=false&server_methods=PUT&server_tabs=local

Note that the preflight request has the header Access-Control-Request-Headers: accept, origin, but there is no Access-Control-Allow-Headers in the response. And the actual CORS request still succeeds.

The Content-Type header is considered a simple request header only when its value is one of the following: application/x-www-form-urlencoded, multipart/form-data, or text/plain. All other values will trigger a preflight. That is probably what you are seeing here.

I have no idea why browsers behave this way. It might be something worth asking on the WebKit or Firefox message boards. Here is the code where WebKit sets the Access-Control-Request-Headers header:

https://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp?order=name#L117

It seems to be listing out all the headers, without removing the simple headers. I imagine there is code on the response side that only expects non-simple headers in the Access-Control-Allow-Headers response.

来源：https://stackoverflow.com/questions/17330302/why-are-non-custom-headers-included-in-access-control-request-headers