HTTP OPTIONS请求可以返回204还是总是返回200？

Question

根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2,有关HTTP OPTIONS请求的唯一回复是200.但是,似乎有这样的情况,例如content-length为0表示204更合适.HTTP OPTIONS请求是否适合返回204？

Answer 1

RFC 2616说:

200响应应该......

...

如果不包括响应主体,则响应必须包括具有字段值"0"的Content-Length字段.

这确实使得不清楚200是适用于整段还是仅适用于第一句.如果你想安全地玩它,你必须优先考虑(它不会花费你太多).

废弃RFC 2616的RFC 7231将措辞改为

生成对OPTIONS成功响应的服务器应该......

...

如果在响应中没有要发送有效载荷主体,则服务器必须生成值为"0"的Content-Length字段.

这使得最后一句在一般意义上适用于2xx状态,并且必须占优势.

因此,必须发送内容长度.但是内容长度不能与204一起发送:

RFC 2616说它是这样的:

通过包含Content-Length或Transfer-Encoding标头字段来表示请求中是否存在消息正文...

...所有1xx(信息),204(无内容)和304(未修改)响应不得包含消息正文.

RFC 7230也澄清了这一点:

服务器不得在状态代码为1xx(信息)或204(无内容)的任何响应中发送Content-Length头字段.

无论如何,这就是我理解它的方式.

Answer 2

是的,它可以返回204.或400.或404.对于方法可以返回的状态代码没有一般限制.

另请注意,现在是时候停止查看RFC 2616.请参阅http://trac.tools.ietf.org/wg/httpbis/trac/wiki.

Answer 3

在现有语言中，解决RFC 7230 \xc2\xa73.3.2Content-Length之间明显矛盾的唯一解决方案：

\n

\xe2\x80\x9cA 服务器不得Content-Length在状态代码为 1xx（信息）或 204（无内容）的任何响应中发送标头字段。\xe2\x80\x9d

\n

和RFC 7231 \xc2\xa74.3.7OPTIONS：

\n

\xe2\x80\x9cContent-Length如果响应中没有发送负载主体，服务器必须生成一个值为“0”的字段。\xe2\x80\x9d

\n

是禁止对OPTIONS请求的所有 204 响应。因为这似乎不是我的本意，所以我提交了一份勘误报告。后一个声明已从Draft-ietf-httpbis-semantics-06中的 RFC 7231 中删除，现在发布为RFC 9110 ，因此现在明确允许204 响应（不带字段）。Content-That

\n