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

Question

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

200、204 还是其他？

在允许源(并且将设置相应的 header )或不允许(并且不会设置 CORS header 或与源不匹配)的情况下，状态代码是否应该不同？

Answer 1

要点是，只需使用 200。

更笼统一点:您应该只为 CORS 预检 OPTIONS 请求发回相同的状态代码，与为任何其他 OPTIONS 请求发回的状态代码相同。相关规范仅要求或推荐任何内容。

规范说明:https://fetch.spec.whatwg.org/ 的 Fetch 规范是定义 CORS 协议(protocol)要求的地方，它表示状态可以是 200-299 范围内的任何值。

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

If a CORS check for request and response returns success and response’s status is
an ok status, run these substeps: …

就什么是“正常状态”而言，规范是这样说的:

An ok status is any status in the range 200 to 299, inclusive.

除此之外，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 预检选项的响应只需:

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

这就是200 OK由 HTTP 规范定义为，因此您可以就此打住。

但是如果你通读the rest of the 2xx codes in that section ，您可以确认它们的语义对于 OPTIONS 响应都没有意义——204 No Content 除外。 .

现在就 204 No Content 而言，将它用于 OPTIONS 响应没有任何错误——但也没有任何意义.那是因为:

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

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

Should the status code be different in case origin is allowed (and corresponding headers will be set) or not allowed (and CORS headers will not be set or will not match the origin)?

没有。除了您可以使用的 200 或 204 之外，没有任何标准定义的代码——但无论如何，规范不要求它有任何不同，也不如果是，请定义任何不同的用途。想一想:由于这两种情况的状态代码存在差异，任何现有的客户端代码会有什么不同？

如果答案是“没什么”，那么就没有必要让它有所不同。

---

鉴于以上所有内容，底线是:只需发送 200 OK 以获取 CORS 预检 OPTIONS 响应。发送除 200 OK 之外的任何代码都没有必要也没有用。