HTTP访问控制（CORS）

头像
specialCoder
     北京
    阅读 12 分钟
    2

    前言

    今天在开发的时候查看网络请求注意到一个很有意思的问题：
    跨域发送post请求时，总是发送两次，第一次是OPTIONS请求，状态码204；第二次才是POST请求，状态码200。
    这里有和我一样的问题描述：https://segmentfault.com/q/10...
    深入的研究发现，这里面的内容不简单，所以有了下面的文章。

    正文

    阅读文章前请先了解 浏览器的同源策略：

    有一篇权威又详细的讲解，移步这里：HTTP访问控制（CORS）

    问题描述

    跨域发送post请求时，总是发送两次，第一次是 OPTIONS 请求，状态码 204；第二次才是POST 请求，状态码 200。

    bVKDLp?w=785&h=266

    OPTIONS的作用

    OPTIONS 请求方法的主要用途有两个：

    1. 获取服务器支持的 HTTP 请求方法；也是黑客经常使用的方法。
    2. 用来检查服务器的性能。例如：AJAX进行跨域请求时的预检，需要向另外一个域名的资源发送一个 HTTP OPTIONS 请求头，用以判断实际发送的请求是否安全。

    为什么会这样

    当一个资源从与该资源本身所在的服务器不同的域或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。

    比如，站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg。网络上的许多页面都会加载来自不同域的 CSS 样式表，图像和脚本等资源。

    出于安全原因，浏览器限制从脚本内发起的跨源 HTTP 请求。 例如，XMLHttpRequest 和 Fetch API 遵循同源策略。 这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源，除非使用 CORS 头文件。
    （译者注：这段描述跨域不准确，跨域不一定是浏览器限制了发起跨站请求，而也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击原理，请求是发送到了后端服务器无论是否跨域！注意：有些浏览器不允许从 HTTPS 的域跨域访问 HTTP，比如 Chrome 和 Firefox，这些浏览器在请求还未发出的时候就会拦截请求，这是一个特例。）

    跨域资源共享（ CORS ）机制允许 Web 应用服务器进行跨域访问控制，从而使跨域数据传输得以安全进行 浏览器支持在 API 容器中（例如 XMLHttpRequest 或 Fetch ）使用 CORS，以降低跨域 HTTP 请求所带来的风险。

    这篇文章适用于网站管理员、后端和前端开发者。CORS 需要客户端和服务器同时支持。目前，所有浏览器都支持该机制。

    概述

    跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）

    简单请求

    简单请求的条件

    某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，请注意，该术语并不属于 Fetch （其中定义了 CORS）规范。若请求满足所有下述条件，则该请求可视为“简单请求”：

    1. 使用下列方法之一
        GET
    HEAD
    POST
    1. Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：
        Accept
    Accept-Language
    Content-Language
    Content-Type （需要注意额外的限制）
    DPR
    Downlink
    Save-Data
    Viewport-Width
    Width

    1. Content-Type 的值仅限于下列三者之一：

       text/plain
 multipart/form-data
 application/x-www-form-urlencoded
    2. 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问。
    3. 请求中没有使用 ReadableStream 对象。

    简单请求的过程

    比如说，假如站点 http://foo.example 的网页应用想要访问 http://bar.other 的资源。http://foo.example 的网页中可能包含类似于下面的 JavaScript 代码：

        var invocation = new XMLHttpRequest();
    var url = 'http://bar.other/resources/public-data/';
       
    function callOtherDomain() {
      if(invocation) {    
        invocation.open('GET', url, true);
        invocation.onreadystatechange = handler;
        invocation.send(); 
      }
    }
    1. 客户端和服务器之间使用 CORS 首部字段来处理跨域权限

    simple_req.png

    • 分别检视请求报文和响应报文

      • 请求报文：

        GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

        请求首部字段 Origin 表明该请求来源于 http://foo.example。

      • 响应报文：

        HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]

        本例中，服务端返回的 Access-Control-Allow-Origin: * 表明，该资源可以被 任意 外域访问。

        Access-Control-Allow-Origin: *

        使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。如果服务端仅允许来自 https://foo.example 的访问，该首部字段的内容如下：

        Access-Control-Allow-Origin: https://foo.example

    预检请求

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

    当请求不是简单请求时，即发送预检请求。如下是一个需要执行预检请求的 HTTP 请求：

    var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
    
function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

......
    流程

    上面的代码使用 POST 请求发送一个 XML 文档，该请求包含了一个自定义的请求首部字段（X-PINGOTHER: pingpong）。另外，该请求的 Content-Type为 application/xml。因此，该请求需要首先发起预检请求。

    prelight.png

    1. 客户端发送请求：

      OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

    2. 服务端响应：

      HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

    3. 预检请求完成之后，发送实际请求：

      POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

    4. 实际的响应

      HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

    浏览器检测到，从 JavaScript 中发起的请求需要被预检。从上面的报文中，我们看到先发送了一个使用 OPTIONS 方法的“预检请求”。

    OPTIONS 是 HTTP/1.1 协议中定义的方法，用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段：

    Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

    首部字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。
    首部字段 Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。服务器据此决定，该实际请求是否被允许。

    预检请求的响应，表明服务器将接受后续的实际请求：

    Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

    首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求。该字段与 HTTP/1.1 Allow: response header 类似，但仅限于在需要访问控制的场景中使用。

    首部字段 Access-Control-Allow-Headers表明服务器允许请求中携带字段X-PINGOTHER与 Content-Type。与 Access-Control-Allow-Methods 一样，Access-Control-Allow-Headers 的值为逗号分割的列表。

    最后，首部字段 Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。

    预检请求与重定向

    大多数浏览器不支持针对于预检请求的重定向。如果一个预检请求发生了重定向，浏览器将报告错误：

    The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight.
    Request requires preflight, which is disallowed to follow cross-origin redirect.

    CORS 最初要求该行为，不过在后续的修订中废弃了这一要求。

    在浏览器的实现跟上规范之前，有两种方式规避上述报错行为：

    • 在服务端去掉对预检请求的重定向；
    • 将实际请求变成一个简单请求。

    如果上面两种方式难以做到，我们仍有其他办法：

    • 发出一个简单请求（使用 Response.url 或 XHR.responseURL）以判断真正的预检请求会返回什么地址。
    • 发出另一个请求（真正的请求），使用在上一步通过 Response.url 或 XMLHttpRequest.responseURL 获得的 URL。

    不过，如果请求是由于存在 Authorization 字段而引发了预检请求，则这一方法将无法使用。这种情况只能由服务端进行更改。

    附带身份凭证的请求

    Fetch 与 CORS 的一个有趣的特性是，可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。

    本例中，http://foo.example 的某脚本向 http://bar.other 发起一个 GET 请求，并设置 Cookies：

    var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true; // important
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

    将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。因为这是一个简单 GET 请求，所以浏览器不会对其发起「预检请求」。但是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。

    cred-req.png

    客户端与服务器端交互示例如下

    • 客户端

      GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2

    • 服务端

      HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

    即使客户端请求中指定了 Cookie 的相关信息，但是，如果 bar.other 的响应中缺失 Access-Control-Allow-Credentials: true，则响应内容不会返回给请求的发起者。

    附带身份凭证的请求与通配符

    对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为 *。

    这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为*，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

    另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。

    HTTP 响应首部字段

    Access-Control-Allow-Origin
    响应首部中可以携带一个 Access-Control-Allow-Origin 字段，其语法如下:

    Access-Control-Allow-Origin: <origin> | *

    其中，origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

    例如，下面的字段值将允许来自 http://mozilla.com 的请求：

    Access-Control-Allow-Origin: http://mozilla.com

    如果服务端指定了具体的域名而非*，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。

    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

    这样浏览器就能够通过 getResponseHeader 访问 X-My-Custom-Header 和 X-Another-Custom-Header 响应头了。

    Access-Control-Max-Age
    Access-Control-Max-Age 头指定了 preflight 请求的结果能够被缓存多久，请参考本文在前面提到的 preflight 例子。

    Access-Control-Max-Age: <delta-seconds>

    delta-seconds 参数表示 preflight 请求的结果在多少秒内有效。

    Access-Control-Allow-Credentials

    1. 客户端将 XHRHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies
    2. Access-Control-Allow-Credentials 头指定了当浏览器的 credentials 设置为 true 时是否允许浏览器读取 response 的内容。

    3. 当用在对 preflight 预检测请求的响应中时，它指定了实际的请求是否可以使用 credentials。请注意：简单 GET 请求不会被预检；如果对此类请求的响应中不包含该字段，这个响应将被忽略掉，并且浏览器也不会将相应内容返回给网页。

      Access-Control-Allow-Credentials: true

      上文已经讨论了附带身份凭证的请求。

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

    Access-Control-Allow-Methods: <method>[, <method>]*

    相关示例见这里。

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

    Access-Control-Allow-Headers: <field-name>[, <field-name>]*

    HTTP 请求首部字段

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

    Origin
    Origin 首部字段表明预检请求或实际请求的源站。

    Origin: <origin>

    origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

    Note: 有时候将该字段的值设置为空字符串是有用的，例如，当源站是一个 data URL 时。
    注意，不管是否为跨域请求，ORIGIN 字段总是被发送。

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

     Access-Control-Request-Method: <method>

    相关示例见这里。

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

     Access-Control-Request-Headers: <field-name>[, <field-name>]*

    从axios再看预检

    defaults.js
    axios/lib/defaults.js 源码里面有这样一段代码：

    var defaults = {
  adapter: getDefaultAdapter(),

  transformRequest: [function transformRequest(data, headers) {
    normalizeHeaderName(headers, 'Content-Type');
    if (utils.isFormData(data) ||  // FormData
      utils.isArrayBuffer(data) || // ArrayBuffer
      utils.isBuffer(data) ||    // Buffer
      utils.isStream(data) ||    // Stream
      utils.isFile(data) ||    // File
      utils.isBlob(data)        // Blob
    ) {
      return data;
    }
    if (utils.isArrayBufferView(data)) {
      return data.buffer;
    }
    if (utils.isURLSearchParams(data)) {
      setContentTypeIfUnset(headers, 'application/x-www-form-urlencoded;charset=utf-8');
      return data.toString();
    }
    if (utils.isObject(data)) {
      setContentTypeIfUnset(headers, 'application/json;charset=utf-8');
      return JSON.stringify(data);
    }
    return data;
  }]
}

    这里有三个重要的函数：

    1. utils.isURLSearchParams(data)：判断 data 是否是 window.URLSearchParams 的实例
    2. utils.isObject(data)：判断 data 是否是个object(不包含 null)
    3. setContentTypeIfUnset：如果没有手动定义过 content-type 值就执行一些操作

    总结：

    1. 通常我们不会将数据转成二进制(ArrayBuffer、Buffer、Blob、Stream)之后再发送给服务器，如果也不是 File、FormData 类型这样的话只存在 utils.isURLSearchParams 和utils.isObject 两种情况；
    2. 我们知道当 content-type:application/json 使用 COSR 跨域请求时会触发预检，所以如果我们没有自己手动设置过 content-type 值，并且 data 是个对象类型，那么就会触发预检。

    后记

    在这篇文章中，我们知道了：

    1. 什么是简单请求和复杂请求？
    2. 什么是预检，什么情况下会预检？
    3. 怎样预检？
    4. axios和预检？

    预检会多发一次请求，如何权衡使用 content-type 避免复杂请求和方便的传递数据之间的利弊是一个值得我们思考的问题。

    参考链接

    httpcors
    specialCoder
    2.2k 声望168 粉丝

    前端 设计 摄影 文学

    « 上一篇
    Shared Event-loop for Same-Origin Windows(译)
    下一篇 »
    前端网络知识目录（持续更新）

    引用和评论

    被 1 篇内容引用
    推荐阅读
    头像
    字符编码系列： base64

    specialCoder阅读 672

    头像
    状态码 406， Not Acceptable, (Spring Boot)

    zZ_jie赞 4阅读 649

    头像
    NGINX 知识总结

    Xavier赞 1阅读 4.2k

    头像
    如何设置Fiddler来拦截Java代码发送的HTTP请求，进行各种问题排查

    注销阅读 2.5k

    头像
    TLSv1.3 Support：主流 Web 客户端和服务端对 TLSv1.3 的支持情况

    sysin阅读 2.5k

    头像
    用JavaScript访问SAP云平台上的服务遇到跨域问题该怎么办

    注销阅读 1.6k

    头像
    一键生成 HTTP + gRPC 混合架构微服务代码：更简单、更灵活、更兼容的微服务系统构建方式

    gvison赞 1阅读 437

    0 条评论
    得票最新