根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2提到的关于 HTTP OPTIONS 请求的唯一响应是 200。但是，似乎有一些情况，例如当content-length 为 0 表示 204 更合适。HTTP OPTIONS 请求返回 204 是否合适？
问问题
17458 次
3 回答
18
RFC 2616 说：
一个 200 响应应该...
...
如果没有包含响应正文，则响应必须包含字段值为“0”的 Content-Length 字段。
这确实使得不清楚 200 是适用于整个段落还是仅适用于第一句。如果你想安全起见，你会让 MUST 优先（而且它不会花费你太多）。
RFC 7231 取代了 RFC 2616，将措辞改为
生成对 OPTIONS 的成功响应的服务器应该...
...
如果没有在响应中发送有效载荷主体，服务器必须生成值为“0”的 Content-Length 字段。
这使得最后一句话在一般意义上适用于 2xx 状态，并且必须占上风。
因此，必须发送 Content-Length。但是不能使用 204 发送 Content-Length：
RFC 2616 是这样说的：
请求中消息体的存在通过包含 Content-Length 或 Transfer-Encoding 标头字段来表示...
... 所有 1xx（信息）、204（无内容）和 304（未修改）响应不得包含消息正文。
RFC 7230 也澄清了这一点：
服务器不得在任何状态码为 1xx（信息）或 204（无内容）的响应中发送 Content-Length 头域。
反正我是这么理解的。
于 2015-07-06T21:37:11.840 回答
9
是的，它可以返回 204。或 400。或 404。对于方法可以返回哪些状态代码没有一般限制。
另请注意，是时候停止查看 RFC 2616。请参阅http://trac.tools.ietf.org/wg/httpbis/trac/wiki。
于 2013-02-05T08:49:29.503 回答
4
在现有语言中，唯一解决RFC 7230 §3.3.2Content-Length之间明显矛盾的方法：
Content-Length“服务器不得在任何状态码为 1xx（信息）或 204（无内容）的响应中
发送标头字段。”</p>
Content-Length“如果没有在响应中发送有效负载正文，
服务器必须生成一个值为“0”的字段。”</p>
是禁止对请求的所有 204 响应OPTIONS。因为这似乎不是本意，所以我提交了一份勘误报告。后一条语句已从Draft-ietf-httpbis-semantics-06中的 RFC 7231 中删除，因此Content-Length现在明确允许204 响应（没有字段）。
于 2019-08-12T02:40:18.090 回答