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

问题描述

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

200、204 还是别的什么?

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

解决方案

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

更一般的一点:您应该只为 CORS 预检 OPTIONS 请求发回相同的状态代码，您会为任何其他 OPTIONS 请求发回相同的状态代码.相关规范不要求或推荐更多内容.

规范说明:https://fetch.spec.whatwg.org/<上的 Fetch 规范/a> 是定义 CORS 协议要求的地方，它表示状态可以是 200-299 范围内的任何内容.

这来自 CORS-preflight 获取算法，在 说明它可以是任何正常状态"的步骤:

<块引用>

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

至于什么是正常状态"，规范是这样说的:

<块引用>

ok 状态 是 200 到 299 范围内的任何状态，包括边界值.

除此之外，Fetch 规范不推荐 200-299 内的任何特定状态.

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

在该部分中，有 200 的特定部分好的，它是这样说的:

200(OK)状态码表示请求成功.200 响应中发送的有效负载取决于请求方法.对于本规范定义的方法，预期含义的payload可以总结为:…OPTIONS 表示通信选项；

因此，对 CORS 预检选项的响应只需:

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

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

但是如果你通读了其余的2xx 代码，您可以确认它们的语义对于 OPTIONS 响应没有任何意义 - 除了 204 无内容.

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

• 与其他一些方法不同，HTTP 规范定义不使用 OPTIONS 有效负载
• 因此在实践中，客户端不希望任何负载(内容)为 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.

What the specs say: 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 anything in the range 200-299.

That’s from the CORS-preflight fetch algorithm, in 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 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.

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 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屋！