为什么非自定义头包括在Access-Control-Request-Headers中？ [英] Why are non-custom headers included in Access-Control-Request-Headers?

问题描述

我想要发送跨来源请求。就 Access-Control-Request-Headers 而言，我在FireFox，Chrome和Safari中获得不同的行为。

  Chrome： - 访问控制请求标头：origin，content-type，accept 
 Safari： - 访问控制请求标头：origin， type，accept 
 Firefox： -  Access-Control-Request-Headers：content-type 
  

我的问题是：

1. 浏览器如何决定哪些标头将成为Access-Control-Request-Headers的一部分？


2. 据我所知，在Access-Control-Request-Headers中应该只有自定义头，但是所有三个（accept，origin和content-type）不是自定义头。


3. 为什么这些行为会因浏览器而异？

<

这里有很多不同的事情，所以我一次回答一个。

Chrome和Safari均基于WebKit，这就是为什么您在这些浏览器中看到的行为相同（Chrome即将推出到Blink，但这还不在用户手中）。

最新的CORS规范规定 Accept 是一个简单的请求头。 原始不包括在简单请求头的列表中，但它是愚蠢的，它不被支持，因为它是CORS的基础。所以技术上Firefox正在做正确的事情。

但请注意，虽然Chrome / Safari包含接受和原始 headers，它们不会验证这些头是否包含在 Access-Control-Allow-Headers 响应头中。您可以通过访问以下链接验证此操作：

http：//client.cors-api。 appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&ser​​ver_enable=true&ser​​ver_status=200&ser​​ver_credentials=false&ser​​ver_methods=PUT&ser​​ver_tabs=local

请注意，预检请求具有头 Access-Control-Request-Headers：accept，origin 但在响应中没有 Access-Control-Allow-Headers 。

Content-Type 头被认为是一个简单的请求头，值是以下之一： application / x-www-form-urlencoded ， multipart / form-data text / plain 。所有其他值将触发预检。这可能是你在这里看到的。

我不知道为什么浏览器的行为是这样的。这可能是值得询问的WebKit或Firefox留言板。下面是WebKit设置 Access-Control-Request-Headers 头文件的代码：

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

似乎列出所有标题，而不删除简单标题。我想象在响应方面有代码，只需要在 Access-Control-Allow-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?

解决方案

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.

这篇关于为什么非自定义头包括在Access-Control-Request-Headers中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！