根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2，有关HTTP OPTIONS请求的唯一回复是200.但是，似乎存在诸如当内容长度为0时204更合适的情况。 HTTP OPTIONS请求是否适合返回204？
答案 0 :(得分：12)
RFC 2616说：
200响应应该......
...
如果不包括响应主体，则响应必须包括a Content-Length字段，字段值为“0”。
确实不清楚200是适用于整段还是仅适用于第一句。如果你想安全地玩它，你必须优先考虑（并且不会花费太多）。
RFC 7231废弃了RFC 2616，将措辞改为服务器生成对OPTIONS的成功响应......
...
如果在响应中没有要发送有效载荷主体，服务器必须生成值为“0”的Content-Length字段。
这使得最后一句在一般意义上适用于2xx状态，并且必须占优势。
因此，必须发送内容长度。但是内容长度无法通过204发送：</ p>
RFC 2616说它是这样的：
通过包含Content-Length或Transfer-Encoding标头字段来表示请求中是否存在消息正文......
... 所有1xx（信息），204（无内容）和304（未修改）响应不得包含消息正文。
RFC 7230也澄清了这一点：
服务器不得在状态代码为1xx（信息）或204（无内容）的任何响应中发送Content-Length头字段。
无论如何，这就是我的理解。
答案 1 :(得分：6)
是的，它可以返回204.或400.或404.对于方法可以返回的状态代码没有一般限制。
另请注意，现在是时候停止查看RFC 2616.请参阅http://trac.tools.ietf.org/wg/httpbis/trac/wiki。
答案 2 :(得分：0)
在现有语言中，唯一解决RFC 7230 §3.3.2 Content-Length之间明显矛盾的方法：
“服务器不得在状态码为1xx（信息性）或204（无内容）的任何响应中发送Content-Length头字段。”
“如果在响应中不发送任何有效载荷主体，则服务器必须生成一个值为{0”的Content-Length字段。”
禁止对OPTIONS请求的所有204响应。由于这似乎不是故意的，因此我提交了erratum report，如果听到回复，将更新此答案。