Page 241 - Web性能权威指南

同源策略的出发点很简单：浏览器存储着用户数据，比如认证令牌、cookie 及其
他私有元数据，这些数据不能泄露给其他应用。如果没有同源沙箱，那么 example.
com 中的脚本就可以访问并操纵 thirdparty.com 的用户数据！

为解决这个问题，XHR 的早期版本都限制应用只能执行同源请求，即新请求的来
源必须与旧请求的来源一致：来自 example.com 的 XHR 请求，只能从 example.com
请求其他资源。如果后续请求不同源，浏览器就拒绝该 XHR 请求并报错。

可是，在某些必要的情况下，同源策略也会给更好地利用 XHR 带来麻烦：如果服
务器想要给另一个网站中的脚本提供资源怎么办？这就是 Cross-Origin Resource
Sharing（跨源资源共享，CORS）的来由！ CORS 针对客户端的跨源请求提供了安
全的选择同意机制：

// 脚本来源：(http, example.com, 80)
var xhr = new XMLHttpRequest();
xhr.open('GET', '/resource.js'); ➊
xhr.onload = function() { ... };
xhr.send();

var cors_xhr = new XMLHttpRequest();
cors_xhr.open('GET', 'http://thirdparty.com/resource.js'); ➋
cors_xhr.onload = function() { ... };
cors_xhr.send();
➊ 同源 XHR 请求
➋ 跨源 XHR 请求

CORS 请求也使用相同的 XHR API，区别仅在于请求资源用的 URL 与当前脚本并
不同源。在前面的例子中，当前执行的脚本来自 (http, example.com, 80)，而第二个
XHR 请求访问的 resource.js 则来自 (http, thirdparty.com, 80)。

针对 CORS 请求的选择同意认证机制由底层处理：请求发出后，浏览器自动追加受保
护的 Origin HTTP 首部，包含着发出请求的来源。相应地，远程服务器可以检查 Origin
首部，决定是否接受该请求，如果接受就返回 Access-Control-Allow-Origin 响应首部：

=> 请求
GET /resource.js HTTP/1.1
Host: thirdparty.com
Origin: http://example.com ➊
...

<= 响应
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example.com ➋
...

228 ｜ 第 15 章