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

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

200,204还是其他什么？

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

它的要点是,只需使用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”：

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

至于“正常状态”是什么,规范说明了这一点：

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

除此之外,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,将它用于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以外的标准定义代码 – 但无论如何,规范并不要求它有任何不同,如果是,则不定义任何不同的用途.并考虑一下：由于这两种情况的状态代码有任何不同,现有客户代码会有什么不同？

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

鉴于以上所有,最重要的是：只需为CORS预检OPTIONS响应发送200 OK.发送除200 OK以外的任何代码不是必需的或有用的.