5

我想更好地理解这一点。我目前使用的心智模型是这样的：

  1. 托管在 foo.com 的 JS 希望访问托管在 bar.com 的资源。这不是浏览器喜欢向用户展示的那种东西，除非可以表明 bar.com 对此请求表示欢迎。
  2. 所以 foo.com JS 本质上将请求分成两半。首先，我们通过 XMLHttpRequest 对象发送适当类型的无数据请求（GET、POST 等）。bar.com 上的服务器返回它通常对基本上任何请求的响应，这些请求可能包含也可能不包含 Access-Control-Allow-Origin 标头。（编辑：这是一个误解 - 请参阅下面的 apsillers 的出色评论）
  3. 如果浏览器确实得到了这样的标题，它会扫描它的 Origin（在本例中为 foo.com）。如果存在，它继续发送它被要求发送的实际请求。如果没有，它会拒绝。（编辑：这也不太正确）

如果这个模型是正确的，我很困惑为什么浏览器会发送一个带有这个初步请求的 Origin 标头。检查匹配不是发生在客户端吗？发送此标头有什么作用？

4

1 回答 1

3

这就是CORS 的工作原理。这基本上是一个握手，表示欢迎您与我交谈。除非联系第三者，否则您无法知道是否有可能。

以下是MDN 文章Preflighted_requests 部分的部分内容：

与简单请求（上面讨论过）不同，“预检”请求首先向另一个域上的资源发送 HTTP OPTIONS 请求标头，以确定实际请求是否可以安全发送。跨站点请求是这样预检的，因为它们可能对用户数据有影响。特别是，在以下情况下会预检请求：

它使用 GET 或 POST 以外的方法。此外，如果 POST 用于发送 Content-Type 不是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 的请求数据，例如，如果 POST 请求向服务器发送 XML 有效负载使用 application/xml 或 text/xml，然后预检请求。它在请求中设置自定义标头（例如，请求使用诸如 X-PINGOTHER 之类的标头）

于 2012-11-19T18:37:54.360 回答