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

Question

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

200、204 还是别的什么？

如果允许来源（并且将设置相应的标头）或不允许（并且不会设置 CORS 标头或与来源不匹配），状态代码应该不同吗？

Answer 1

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

更笼统地说：您应该为 CORS 预检 OPTIONS 请求发回与任何其他 OPTIONS 请求相同的状态代码。相关规范不要求或推荐除此之外的任何内容。

规范内容：https://fetch.spec.whatwg.org/ 的 Fetch 规范定义了 CORS 协议的要求，它说状态可以是 200-299 范围内的任何内容。

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

如果对 request 和 response 的 CORS 检查返回成功并且 response 的状态是
ok status，运行这些子步骤：……

至于什么是“正常状态”，规范是这样说的：

ok 状态是200 到299 范围内的任何状态，包括端点。

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

这里的另一个相关规范是 HTTP 1.1 规范，其中有一个部分定义了所有 HTTP 响应状态代码的语义，其中包含a 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 而言，将它用于OPTIONS 响应并没有错误 - 但据我所知，这也没有任何意义。那是因为：

• 与其他一些方法不同，HTTP 规范定义了OPTIONS 有效载荷的用途
• 因此，在实践中，客户端不希望任何有效负载（内容）返回 OPTIONS（并且不会对返回的任何有效负载执行任何操作）

…据我所知，在OPTIONS 响应中使用特定的204 状态代码来明确告诉客户端没有有效负载没有实际目的。

在允许来源（并且将设置相应的标头）或不允许（并且不会设置 CORS 标头或与来源不匹配）的情况下，状态代码应该不同吗？

不，我不认为应该有所不同。我不知道除了200 或204 之外你还可以使用什么标准定义的代码——但不管怎样，规范并不要求它有任何不同，并且如果它没有定义任何不同的用途是。想一想：由于这两种情况下状态代码的不同，任何现有的客户端代码会有什么不同？

如果答案是，“没什么”，在我看来，让它与众不同是没有意义的。

---

鉴于以上所有情况，底线是：只需发送 200 OK 以获得 CORS 预检 OPTIONS 响应。发送除 200 OK 以外的任何代码都没有必要或有用。

Answer 2

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

经验教训：当对 Web 标准有疑问时，不要选择明智的规范（即 204 表示没有内容）...选择大多数人所做的（简单/愚蠢的选择）