Page 242 - Web性能权威指南

➊ Origin 首部由浏览器自动设置
➋ 选择同意首部由服务器设置

在前面的例子中，thirdparty.com 决定同意与 example.com 跨源共享资源，因此就在
响应中返回了适当的访问控制首部。假如它选择不同意接受这个请求，那么只要不
在响应中包含 Access-Control-Allow-Origin 首部即可。这样，客户端的浏览器就会
自动将发出的请求作废。

如果第三方服务器不支持 CORS，那么客户端请求同样会作废，因为客户
端会验证响应中是否包含选择同意的首部。作为一个特例，CORS 还允许
服务器返回一个通配值 (Access-Control-Allow-Origin: *)，表示它允许
来自任何源的请求。不过，在启用这个选项前，请大家务必三思！

这就是全部了吧？准确地讲，不是。因为 CORS 还会提前采取一系列安全措施，以
确保服务器支持 CORS：

• CORS 请求会省略 cookie 和 HTTP 认证等用户凭据；
• 客户端被限制只能发送“简单的跨源请求”，包括只能使用特定的方法（GET、
POST 和 HEAD），以及只能访问可以通过 XHR 发送并读取的 HTTP 首部。

要启用 cookie 和 HTTP 认证，客户端必须在发送请求时通过 XHR 对象发送额外
的属性（withCredentials），而服务器也必须以适当的首部（Access-Control-Allow-
Credentials）响应，表示它允许应用发送用户的隐私数据。类似地，如果客户端需要
写或者读自定义的 HTTP 首部，或者想要使用“不简单的方法”发送请求，那么它
必须首先要获得第三方服务器的许可，即向第三方服务器发送一个预备（preflight）
请求：

=> 预备请求
OPTIONS /resource.js HTTP/1.1 ➊
Host: thirdparty.com
Origin: http://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: My-Custom-Header
...

<= 预备响应
HTTP/1.1 200 OK ➋
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: My-Custom-Header
...

（正式的 HTTP 请求） ➌

XMLHttpRequest ｜ 229