RFC 2616 HTTP 内容长度和传输编码兼容性答案

【问题标题】：RFC 2616 HTTP Content-Length and Transfer-Encoding CompatibilityRFC 2616 HTTP 内容长度和传输编码兼容性
【发布时间】：2019-03-30 19:33:24
【问题描述】：

RFC 2616 声明如果存在Transfer-Encoding，则不得发送Content-Length 标头。

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

但是，如果两个标头都收到，客户端应该忽略Content-Length

如果接收到的消息同时带有 Transfer-Encoding 标头字段和 Content-Length 标头字段，则必须忽略后者。

我的解释是否正确，客户端应该将两个标头都存在的情况视为正确的 HTTP 响应？还是这个子句的具体实现？

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

【问题讨论】：

标签： http go

【解决方案1】：

标准并没有真正指定在这种情况下应该发生什么，只是如果消息被完全接受，那么Content-length 应该被忽略。引用RFC 7230：

如果接收到的消息同时带有 Transfer-Encoding 和 Content-Length 头域，Transfer-Encoding 覆盖内容长度。这样的消息可能表明试图执行请求走私（第 9.5 节）或响应拆分（第 9.4 节）并且应作为错误处理。

请注意这里的弱“应该”，这远非必须。但至少net/http 是完全正确的，因为这种响应是错误的，可以作为错误处理。但它不需要被视为错误。

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

【讨论】：