Ajax 为什么访问控制请求标头中包含非自定义标头？

我正在尝试发送跨来源请求。至于

访问控制请求头

，我在FireFox、Chrome和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

我的问题是：-

浏览器如何决定哪些标头将成为访问控制请求标头的一部分

据我所知，在访问控制请求头中应该只有自定义头，但所有三个（accept、origin和content-type）都不是自定义头。那么为什么它们是访问控制请求头的一部分呢

为什么浏览器的行为会有所不同

---

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

Chrome和Safari都基于WebKit，这就是为什么你在这些浏览器中看到了相同的行为（Chrome很快就会闪烁，但这还不在用户手中）

最新的CORS规范规定，

Accept

是一个简单的请求头<代码>原产地< /代码>不包含在简单请求头的列表中，但它不被支持是愚蠢的，因为它是CORS的基础。所以从技术上讲，Firefox做的是正确的

但是请注意，尽管Chrome/Safari包含

Accept

和

Origin

头，但它们并不验证这些头是否包含在

访问控制允许头

响应头中。您可以通过访问以下链接来验证这一点：

请注意，飞行前请求有头

访问控制请求头：accept，origin

，但响应中没有

访问控制允许头。而实际的CORS请求仍然成功

仅当
内容类型
头的值为以下值之一时，才将其视为简单请求头：
应用程序/x-www-form-urlencoded
、
多部分/表单数据
或
文本/普通
。所有其他值将触发预飞行。这可能就是你在这里看到的

我不知道浏览器为什么会这样。这可能是值得在WebKit或Firefox留言板上询问的问题。以下是WebKit设置访问控制请求头的代码：


它似乎列出了所有的头，而没有删除简单的头。我想象在响应端有一个代码，在
Access Control Allow headers
response中只需要非简单的头。
hi另外一件事是使用chrome我正在设置头值dauth。但在fiddler中，它向我显示了访问控制请求标题：content-type、dauth、x-akamai-acs-action。然而，如果我——解除chrome的web安全性，它会向我显示DAUTH:XXXXXXX值……你知道为什么在前面的例子中不附加头值吗