Question

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

200，204或其他什么？

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

Answer 1

它的要点是，只需使用200。

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

相关规范：https://fetch.spec.whatwg.org/的Fetch规范是定义CORS协议要求的地方，它表示状态可以是200 - 299范围内的任意值

这来自CORS-preflight fetch algorithm，其中有a step saying it can be any “ok status"：

如果对请求和响应的CORS检查成功并且响应的状态为ok status ，运行这些子步骤：...

就“状态”而言，规范说明了这一点：

确定状态是200到299范围内的任何状态。

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

此处的其他相关规范是HTTP 1.1规范，其中有一节定义了所有HTTP响应状态代码的语义，并在其中包含a specific section that defines Successful 2xx代码。

在该部分中有a specific section for 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响应标题）

这就是HTTP规范定义的200 OK，所以你可以在那里停下来。

但是，如果您通读the rest of the 2xx codes in that section，则可以确认其中没有任何一种语义对OPTIONS响应有意义 - 204 No Content除外。

现在，就204 No Content而言，错误并没有将{em>错误用于OPTIONS响应 - 但据我所知，也没有任何意义。那是因为：

与其他一些方法不同，HTTP规范定义了OPTIONS有效负载
因此在实践中，客户不希望任何有效载荷（内容）返回OPTIONS（并且不会对任何有效载荷做任何事情）

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

但是，我可能错了，而且我有一些细微差别。但我不这么认为。

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

不，我认为不应该有所不同。我不知道您可以使用的200或204以外的标准定义代码 - 但无论如何，规范并不要求它有任何不同，也不要定义任何不同的用途，如果是的话。并考虑一下：由于这两种情况的状态代码有任何不同，现有的客户代码会有什么不同呢？

如果问题的答案是，“Nothing”，据我所知，没有必要让它与众不同。

鉴于上述所有情况，最重要的是：只需发送200 OK进行CORS预检OPTIONS响应。发送除200 OK以外的任何代码不是必需或有用的。

Answer 2

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

要学习的经验：当对网络标准存有疑问时，不要选择有意义的规范（即204（不包含任何内容））...选择大多数人的行为（简单/愚蠢的选择）

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

2 个答案: