RFC 2616 HTTP内容长度和传输编码兼容性 [英] RFC 2616 HTTP Content-Length and Transfer-Encoding Compatibility

问题描述

RFC 2616 指出，如果Transfer-Encoding存在.

如果这两个长度不同(即，如果存在Transfer-Encoding标头字段)，则不得发送Content-Length标头字段.

The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present).

但是，如果同时接收到两个标头，则客户端应忽略Content-Length

However, if both headers are received, the client should ignore the Content-Length

如果同时收到带有传输编码头字段和内容长度头字段的消息，则必须忽略后者.

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

我的解释是否正确，即客户端应将两个标头都存在的情况视为正确的HTTP响应?还是该条款的实现是特定的?

Is my interpretation correct that the client should treat the case where both headers are present as a proper HTTP response? Or is this clause implementation specific?

我问是因为Go标准net/http程序包在发生这种情况时会返回错误.

I'm asking because the Go standard net/http package returns an error when such scenario happens.

推荐答案

该标准并未真正指定在这种情况下应发生的情况，仅当完全接受该消息时，才应忽略Content-length.引用 RFC 7230 :

The standard does not really specify what should happen in this case, only that if the message is accepted at all then the Content-length should be ignored. To cite from RFC 7230:

如果同时接收到带有传输编码和 Content-Length标头字段中， Transfer-Encoding会覆盖 内容长度.这样的消息可能表明试图 执行请求走私(第9.5节)或响应拆分 (第9.4节)和应作为错误处理.

If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error.

请注意此处弱的应做" ，它与MUST距离很远.但是至少net/http是完全正确的，因为这种响应是错误的，并且可以作为错误处理.但这不要求被视为错误.

Note the weak "ought to" here which is far from MUST. But at least net/http is fully correct in that this kind of response is wrong and can be handled as error. But it is not required to be treated as error.

实际上，所有浏览器似乎都接受这样的响应，并且通常会忽略Content-length标头.但是我过去曾看到过MS Edge的一种行为，该行为将响应主体正确地视为分块，但另外使用了Content-length，并且忽略了响应主体中未被Content-length覆盖的任何字节.

In practice all browsers seem to accept such a response and usually ignore the Content-length header. But I've seen als a behavior with MS Edge in the past where it correctly treated the response body as chunked but additionally used Content-length and ignored any bytes from the response body not covered by the Content-length.

这篇关于RFC 2616 HTTP内容长度和传输编码兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！