在执行预检请求时是否需要Access-Control-Allow-Origin CORS标头？

Question

我们在网站上看到了众所周知的CORS错误：

  

XMLHttpRequest无法加载https://my-site.com/api。请求的资源上不存在“Access-Control-Allow-Origin”标头。因此，不允许原点“https://my-other-site.com”访问。

问题是，在预检请求中正确设置了Access-Control-Allow-Origin ...

OPTIONS https://my-site.com/api HTTP/1.1
Host: my-site.com
Access-Control-Request-Method: POST
Origin: https://my-other-site.com
Access-Control-Request-Headers: my-custom-header, accept, content-type
Accept: */*
Referer: https://my-other-site.com/
...other stuff...


HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://my-other-site.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: my-custom-header, accept, content-type
Access-Control-Expose-Headers: my-custom-header
...other stuff...

...但是，在后续请求中设置了 。

POST https://my-site.com/api HTTP/1.1
Host: my-site.com
Accept: */*
My-Custom-Header: abcd123
Origin: https://my-other-site.com
Referer: https://my-other-site.com/
...other stuff...


HTTP/1.1 200 OK
My-Custom-Header: abcd123
...other stuff...

我不明白这个问题。根据我在线阅读的所有，如果我们使用预检请求，我们不需要为实际请求添加CORS头。然而，事实显然并非如此。

所有示例here和here在实际响应中都包含Access-Control-Allow-Origin标头，但不包含任何其他“required” CORS标题。当我们将一个标题添加到实际响应中时，错误就会消失。

---

所以我的问题是，是两个请求中实际需要的Access-Control-Allow-Origin标头吗？那说明了哪里？为什么这是真的？

Answer 1

是的，似乎两个响应都应包含必要的CORS标头。

在Simple Cross-Origin Request和Cross-Origin Request with Preflight中，＆＃34;实际请求＆＃34;遵循相同的行为，检查CORS标头，无论预检（分别为步骤1和步骤3）。

  

  

1. [...]在提出请求时应用make a request steps并观察下面的请求规则。

        
     

   • ...（剪切：3xx代码，中止和网络错误）

     

   • ，否则

          

     执行resource sharing check。 [...]

     
  

  

给定资源的资源共享检查算法如下：

     

  

1. 如果响应包含零个或多个Access-Control-Allow-Origin标头值，则返回失败并终止此算法。

  

2. [...]

  

预检请求仅阻止＆＃34;实际请求＆＃34;从一开始。