当HTTP服务器接收到CORS预检请求(OPTIONS
)时,一个好的HTTP服务器应该返回哪个状态码?
200
、204
或其他什么状态码?
如果允许来源(并设置相应的标头),或者不允许(CORS标头将未设置或与来源不匹配),状态码是否应不同?
当HTTP服务器接收到CORS预检请求(OPTIONS
)时,一个好的HTTP服务器应该返回哪个状态码?
200
、204
或其他什么状态码?
如果允许来源(并设置相应的标头),或者不允许(CORS标头将未设置或与来源不匹配),状态码是否应不同?
200
。OPTIONS
请求,应该发送与其他OPTIONS
请求相同的状态码。相关规范不需要或建议更多的操作。200
-299
范围内的任何值。至于“ok status”的含义,规范如下:如果请求和响应的CORS检查返回成功,并且响应的状态为ok status,则运行以下子步骤:…
除此之外,Fetch规范并不推荐在200-299范围内选择任何特定状态码。ok status是指范围在
200
到299
之间的任何状态。
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
,所以你可以在这里停止。
但是如果你阅读该部分其余的2xx
代码, 你会确认它们的语义对于一个OPTIONS
响应来说都没有意义,除了204 No Content
。
现在就204 No Content
而言,使用它作为OPTIONS
响应并没有什么问题——但也没有任何意义。那是因为:
OPTIONS
有效载荷的使用方式OPTIONS
有效载荷(内容)返回(并且不会对任何返回的有效载荷采取任何操作)...因此,在OPTIONS
响应中使用特定的204
状态码明确告诉客户端没有有效载荷是没有实际目的的。
如果允许来源(并设置相应标头)或不允许(CORS标头将不会设置或不匹配来源),状态码是否应该不同?
不需要。无论如何,除了200
或204
之外,您都不能使用任何标准定义的代码-但是无论如何,规范不要求其有任何不同,并且如果它是,则不定义任何不同的用途。而且想想看:由于这两种情况下状态码的任何差异,任何现有的客户端代码会有什么不同的操作?
如果答案是“没有”,那么没有必要使它变得不同。
200 OK
即可。发送除200 OK
以外的任何代码都是不必要且无用的。204
。现在它在跨浏览器中不再起作用了。请使用200
。如果预检接收到204
,Firefox将开始拒绝CORS请求。这浪费了我近2个小时的调试时间。204
)......而是选择大多数人都在使用的方法(即简单/愚蠢的选择)。