CORS 原理

CORS 是跨域的一种解决方案，服务端在响应头设置允许跨域的origin，浏览器便可以访问加载这些资源。另外还引入了预检请求，在预检请求中，浏览器发送的头中标示有HTTP方法和真实请求中会用到的头。预检请求成功后，才会发起真实的请求。详细介绍见 MDN CORS，其中3个关键点：

• CORS 允许服务器标识其他origin，让对应的客户端可以加载这个下的资源
• CORS 使用了 HTTP 头字段
• CORS 还额外使用了预检请求：简单请求不会进行预检请求，非简单请求会进行预检请求

假设没有预检请求时，客户端发起请求，服务端处理(比如修改数据)并响应，但是客户端跨域导致无法获取响应内容，导致无法判断服务端做了怎样的处理，所以引入了预检请求，用来协商是否支持跨域。消除前者副作用。

1. 简单请求

某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，关于简单请求的限制：

• 请求方法：使用 GET/HEAD/POST
• 头部字段：5个
  • 用户代理自动设置的首部字段（例如 Connection ，User-Agent）
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （需要注意额外的限制）
• Content-Type 值限制
  • text/plain
  • multipart/form-data
  • application/x-www-form-urlencoded
• 请求中没有使用 ReadableStream 对象。
• 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器

最后一个是最难遵守的，所以我们真实开发中，大部分情况下都是非简单请求。

2. 预检请求

与前述简单请求不同，“需预检的请求”要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

image.png
该图中，服务端响应 Access-Control-Allow-Origin：*，即对请求来源origin不做限制。下面是一个 preflight request + main request 的例子：
image.png

• Access-Control-Allow-Methods：表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求，仅限于在需要访问控制的场景中使用。
• Access-Control-Allow-Headers：表明服务器允许请求中携带字段 X-PINGOTHER 与 Content-Type。与 Access-Control-Allow-Methods 一样，Access-Control-Allow-Headers 的值为逗号分割的列表。
• 首部字段 Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。

3. 响应字段

2.1 Access-Control-Allow-Origin

设置允许跨域的 origin，可以使用具体的origin，也可以使用*来标识所有的origin都可以访问；

2.2 Access-Control-Expose-Headers

在跨源访问时，XMLHttpRequest对象的getResponseHeader()方法只能拿到一些最基本的响应头，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。Access-Control-Expose-Headers 头让服务器把允许浏览器访问的头放入白名单，例如：

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

2.3 Access-Control-Max-Age

Access-Control-Max-Age 头指定了preflight请求的结果能够被缓存多久。之前我还好奇为什么不是每一个请求都要预请求，原来可以缓存。

2.4 Access-Control-Allow-Credential

Access-Control-Allow-Credentials 头指定了当浏览器的 credentials 设置为 true 时是否允许浏览器读取response 的内容。当用在对 preflight 预检测请求的响应中时，它指定了实际的请求是否可以使用 credentials

2.5 Access-Control-Allow-Methods

Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。

2.6 Access-Control-Allow-Headers

Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。

4. 请求字段

本节列出了可用于发起跨源请求的首部字段。请注意，这些首部字段无须手动设置。 当开发者使用 XMLHttpRequest 对象发起跨源请求时，它们已经被设置就绪。

4.1 Origin

Origin 首部字段表明预检请求或实际请求的源站。origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

4.2 Access-Control-Request-Method

Access-Control-Request-Method 首部字段用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。

4.3 Access-Control-Request-Headers

Access-Control-Request-Headers 首部字段用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。

5. 附带身份凭证的请求

一般而言，对于跨源 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
        // 设置跨域携带 cookie
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“*”。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。