什么是CORS预检请求的正确状态代码？

Question

编写良好的HTTP服务器在获得CORS预检(OPTIONS)请求时应返回什么状态代码？

200,204还是其他什么东西？

如果允许原点(并且将设置相应的标题)或不允许(并且CORS标题不会被设置或与原点不匹配),状态代码是否应该不同？

Answer 1

它的要点是,只需使用200.

更一般地说:您应该发送回OPTIONS您为任何其他OPTIONS请求发回的CORS预检请求的相同状态代码.相关规范不要求或推荐任何其他内容.

至于相关规范:https : //fetch.spec.whatwg.org/上的Fetch规范是定义CORS协议要求的地方,它表示状态可以是范围内的任何变化200- 299.

这是来自CORS-preflight fetch算法,它有一个步骤说它可以是任何"ok status":

如果CORS支票的请求和响应返回成功,响应的状态是
一个正常状态,运行这些子步骤:...

至于"正常状态"是什么,规范说明了这一点:

一个好的状态是在范围内的任何状态200到299,包容性.

除此之外,Fetch规范不建议在200- 中的任何特定状态299.

这里的另一个相关规范是HTTP 1.1规范,它具有定义所有HTTP响应状态代码的语义的部分,并且在其中,定义成功2xx代码的特定部分.

在该部分中有一个200 OK的特定部分,其中说:

The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
…
OPTIONS  a representation of the communications options;

因此,对CORS预检OPTIONS的响应只需要:

• 表示请求已成功
• 通信选项的表示(在本例中包括Access-Control-Allow-Methods和Access-Control-Allow-Headers响应头)

这200 OK就是HTTP规范定义的内容,因此您可以在那里停止.

但是如果你仔细阅读该部分中的其余2xx代码,你可以确认它们的语义没有一个对于OPTIONS响应有意义- 除了204 No Content.

现在,将它用于响应204 No Content并没有错OPTIONS - 但据我所知,也没有任何意义.那是因为:

• 与其他一些方法不同,HTTP规范定义了OPTIONS有效负载的使用
• 因此在实践中,客户不希望任何有效载荷(内容)返回OPTIONS(并且不会对任何有效载荷返回)

...所以据我所知,204在OPTIONS响应中使用特定的状态代码来明确地告诉客户没有有效负载是没有实际意义的.

但是,我可能错了,而且我缺少一些细微差别.但我不这么认为.

如果允许原点(并且将设置相应的标题)或不允许(并且CORS标题不会被设置或与原点不匹配),状态代码是否应该不同？

不,我认为不应该有所不同.我不知道除了200或者204你可以使用什么标准定义的代码- 但不管怎样,规范不要求它有任何不同,如果是,则不定义任何不同的用途.并考虑一下:由于这两种情况的状态代码有任何不同,现有客户代码会有什么不同？

如果这个问题的答案是"没什么",据我所知,没有必要让它与众不同.

鉴于以上所有,底线是:只发送200 OKCORS预检OPTIONS响应.发送除正义之外的任何代码200 OK不是必需的或有用的.

Answer 2

我用过204。现在它不再跨浏览器工作了。使用200. 如果204在预检中收到，Firefox 开始拒绝 CORS 请求。它浪费了我将近 2 个小时的调试时间。

学习经验：当对 Web 标准有疑问时，不要选择合理的规范（即204没有内容）...选择大多数人所做的（简单/愚蠢的选择）