什么是CORS预检请求的正确状态代码？ [英] What are proper status codes for CORS preflight requests?

问题描述

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

200 ， 204 或其他什么？

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

解决方案

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

更一般地说：您应该只发回CORS预检的相同状态代码 OPTIONS 请求您要发送回任何其他选项请求。相关规范不要求或推荐任何更多。

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

这是来自 CORS-preflight fetch algorithm ，其一步说它可以是任何ok status：

如果对请求和响应的CORS检查成功并且响应的状态是
确定状态，运行以下子步骤：...

至于ok status是什么，th e规范说：

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

超越但是，Fetch规范不建议 200 - 299 中的任何特定状态。

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

在该部分中有 200 OK <的特定部分/ a>，它说：

  200（OK）状态代码表示请求已成功。 
 200响应中发送的有效负载取决于请求方法。 
对于本规范定义的方法，有效载荷的预期含义
可归纳为：
 ... 
选项表示通信选项; 
  

因此，对CORS预检OPTIONS的响应只需要：

• 表示请求已成功


• 表示通信选项（在本例中包含 和 Access-Control-Allow-Headers 响应标题）

<这就是 200 OK 由HTTP规范定义，因此您可以在那里停止。

但如果您通读了该部分的其余 2xx 代码，你可以说确定其中没有一个语义可用于 OPTIONS 响应 - 除了 204无内容 。

现在最远 204没有内容去了，没有错误的使用它来 OPTIONS 回复 - 但是我可以看到，也没有任何意义。这是因为：

• 与其他一些方法不同，HTTP规范定义了 OPTIONS payload


• 因此在实践中，客户不希望任何有效载荷（内容）返回 OPTIONS （和对任何有效的有效负载都不会做任何事情。）

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

尽管如此，我可能错了，而且我缺少一些细微差别。但我不这么认为。

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

不，我不认为它应该与众不同。我不知道除了 200 或 204 之外还有什么标准定义的代码 - 但无论如何，规格不要求它有任何不同，如果是，则不定义任何不同的用途。并考虑一下：由于这两种情况的状态代码有任何不同，现有客户代码会有什么不同？

如果对该问题的回答是，没什么，据我所知，没有必要让它与众不同。

---

考虑到上述所有情况，底线是：只需发送 200 OK 进行CORS预检 OPTIONS 回复。发送除 200 OK 之外的任何代码都没有必要或没用。

What status code should a well-written HTTP server return when it gets a CORS preflight (OPTIONS) request?

200, 204 or something else?

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)?

解决方案

The gist of it is, just use 200.

A little more generally: You should just send back the same status code for the CORS preflight OPTIONS request that you’d send back for any other OPTIONS request. The relevant specs don’t require or recommend anything more than that.

As far the relevant specs: The Fetch spec at https://fetch.spec.whatwg.org/ is where requirements for the CORS protocol are defined, and it says the status can be anyhing in the range 200-299.

That’s from the CORS-preflight fetch algorithm, which has 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: …

And as far as what an "ok status" is, the spec says this:

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

Beyond that though, the Fetch spec doesn’t recommend any particular status within 200-299.

The other relevant spec here is the HTTP 1.1 spec, which has a section defining semantics of all HTTP response status codes, and within that, a specific section that defines Successful 2xx codes.

And within that section there’s a specific section for 200 OK, which says this:

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;

So a response to a CORS preflight OPTIONS just needs to be:

• an indication that the request has succeeded
• a representation of the communication options (which in this case includes the Access-Control-Allow-Methods and Access-Control-Allow-Headers response headers)

That’s what 200 OK is defined by the HTTP spec to be, so you can stop right there.

But if you read through the rest of the 2xx codes in that section, you can confirm the semantics of none of them make sense for an OPTIONS response—except for 204 No Content.

Now as far as 204 No Content goes, there’s nothing wrong with using it for OPTIONS responses—but as far as I can see, there’s also not really any point. That’s because:

• unlike for some other methods, the HTTP spec defines no use for an OPTIONS payload
• therefore in practice, clients don’t expect any payload (content) to come back for an OPTIONS (and wouldn’t do anything with any payload that did come back)

…so as far as I can see there’s no practical purpose in using a specific 204 status code in an OPTIONS response to explicitly tell clients there’s no payload.

It’s possible I could be wrong, though, and there’s some nuance I’m missing. But I don’t think so.

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)?

No, I don’t think it should be different. I don’t know what standard-defined code other than 200 or 204 you could use anyway—but regardless of that, the specs don’t require it to be any different and don’t define any different use if it is. And think about it: What is any existing client code going to do any differently due to any difference in the status codes for those two cases?

If the answer to that question is, "Nothing", as far as I can see there’s no point in making it different.

---

Given all the above, the bottom line is: just send 200 OK for CORS preflight OPTIONS responses. Sending any code other than just 200 OK isn’t necessary or useful.

这篇关于什么是CORS预检请求的正确状态代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！