导致 PREFLIGHT 的 HTTP 标头 - 澄清？答案

【问题标题】：HTTP headers which cause PREFLIGHT - Clarification?导致 PREFLIGHT 的 HTTP 标头 - 澄清？
【发布时间】：2015-12-24 01:43:22
【问题描述】：

简单请求是满足以下条件的请求：

HTTP 方法匹配（区分大小写）以下之一：
- 头
- 获取
- 发布
HTTP 标头匹配（不区分大小写）：
- 接受
- 接受语言
- 内容-语言
- 最后一个事件 ID
- Content-Type，但仅当值为以下之一时：
  - application/x-www-form-urlencoded
  - 多部分/表单数据
  - 文本/纯文本

但是看看这个test page 并没有引起 preflight 请求：

一般：

Remote Address:69.163.243.142:80
Request URL:http://aruner.net/resources/access-control-with-get/
Request Method:GET
Status Code:200 OK

请求标头

Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,he;q=0.6
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:aruner.net
Origin:http://arunranga.com
Pragma:no-cache
Referer:http://arunranga.com/examples/access-control/simpleXSInvocation.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

响应标头

Access-Control-Allow-Origin:http://arunranga.com
Connection:Keep-Alive
Content-Type:application/xml
Date:Sat, 26 Sep 2015 09:00:26 GMT
Keep-Alive:timeout=2, max=100
Server:Apache
Transfer-Encoding:chunked

书呆子看着request部分，前面的标准部分中有很多不是的标题：

Cache-Control 不在列表中
Connection 不在列表中
DNT 不是不在列表中
User-Agent 不在列表中
Accept-Encoding 不在列表中

我知道这些更多的是“通用”标题。但是accept-language

也是如此

问题

我在这里缺少什么？根据标准部分，带有这些标头的请求应该引起预检请求。

【问题讨论】：

标签： http http-headers cors preflight

【解决方案1】：

查看您的代码：

    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send();

您实际上并没有设置任何自定义标题。例如

    invocation.setRequestHeader("X-Requested-With", "XMLHttpRequest");

因此不会进行预检。默认浏览器标题不算。预检机制仅用于确保接收站点允许跨域传递任何自定义标头，例如我上面示例中的标头。

【讨论】：

【解决方案2】：

在已接受答案的基础上进一步澄清：请参阅Fetch Standard 的HTTP header layer division 部分（这些天定义了 CORS 协议和 UA 要求）。

为了获取，平台有一个 API 层（HTML 的 img, CSS' background-image), early fetch layer, service worker layer, 以及网络和缓存层。 Accept 和 Accept-Language 设置在早期获取层（通常由用户代理）。大多数其他由用户代理控制的标头，例如Accept-Encoding， Host 和 Referer 设置在网络和缓存层中。开发者可以在 API 层或服务中设置标头工作层（通常通过Request 对象）。

因此，基于此，我们基本上可以说：

问题中的标头由 UA 控制，并设置在“网络和缓存层”中
所以，标头不是开发人员可以在“API 层”中设置的标头
因此，当算法运行以确定是否需要预检请求时，标头尚未设置（相反，它们稍后由 UA 设置，之后已经完成）

那么，鉴于上述情况，尽管可以在请求中看到这些标头，但我们知道它们在确定是否需要预检方面没有任何作用。

换句话说，这些标头本质上与 CORS 无关。同样，相关的唯一标头是开发人员在“API 层”或服务工作者层中手动设置的标头。

【讨论】：