在HTTP请求/响应期间，您如何确定消息体的存在和长度，特别是，是否需要使用请求方法作为输入？
但我对请求和响应都感兴趣 this question asks about the requests's message-body's existance and length，它看起来应该只能在标题上确定（即使用§4.4 of RFC2616中指定的方法）这对请求有好处，但同样可以对响应做同样的事情吗？
RFC2616 §4.4似乎表明相同的算法应该用于请求和响应（因为它在消息体的通用术语中说话），所以这似乎表明可以一般地完成。
然而，HEAD method像拇指一样伸出拇指：Content-Length在响应期间作为标题的一部分发回，但没有身体。
HEAD是特别的，也是唯一的特殊方法吗？或者extension method可以有类似的行为，因此我实际上需要知道 - 对于每种方法 - 该方法是否需要特殊处理。 （因此，除非在HTTP之外进行预先协商，否则不能使用扩展方法。）
答案 0 :(得分：1)
TL; DR - 否 - 在不知道请求方法的情况下，HTTP库无法100％可靠地确定响应的消息体的存在，这与规范关于使用相同的其他观点相矛盾处理请求和响应的算法。
更新：正如@JulianReschke所提到的那样，规范的那一部分已被重写。以下是我自己的经验证据，以进一步支持说明这一点。
§4.4详细说明了确定真实“消息长度”的许多因素，并将响应类型（＃1）列为“优先级”高于Content-length标题的值（＃3） ）。特别是，它提到“对HEAD请求的任何响应”都是“不得包含消息体”的那些。因此，即使服务器发送错误的标头，客户端也应该知道根据响应类型忽略它。这一点似乎非常严格地遵循（如下所示），因此关于对请求和响应使用相同算法的另一点似乎是不真实的。
事实上，我尝试使用不同的HEAD请求命中我自己的Apache服务器，并且Content-length的结果与一致性的结果大不相同，以及它对请求的工作方式。以下是我发送的请求和我收到的回复的相关部分
请求：HEAD /
回复：200 OK
内容长度：1639
我的网络根包含index.html，1639是该文件的大小（以字节为单位）。这是不一致。在这种情况下，它应该发送内容长度为0，因为无论文件大小如何，此响应本身都没有消息体。
请求：HEAD /someproject
回复：301 Moved Permanently
/someproject是一个目录，Apache希望在请求URI的末尾看到斜杠，因此会抛出301错误。显然，因为响应是错误，所以根本不发送内容长度，这个省略被解释为0。这是一致。
请求：GET /someproject
回复：301 Moved Permanently
内容长度：386
使用GET而不是HEAD再次尝试，现在我获得Apache自动生成的错误页面的内容长度以附加301标头。这是一致，虽然根据它如何处理上述两个HEAD请求有点奇怪。
请求：HEAD /someproject
Accept-Encoding：gzip，deflate
回复：301 Moved Permanently
内容长度：20
返回HEAD，但请求gzipped响应。这次我得到内容长度20，这是应用gzip编码后空响应的大小。这个将是一致的，但是没有发送实际的20字节gzip压缩消息（大概是因为它是HEAD请求）！
请求：HEAD /someproject/
回复：200 OK
该目录确实包含index.php，但与返回index.html的文件大小的第一个示例不同，此处Apache不希望执行PHP脚本来查找实际响应的内容长度，所以它将其视为0。这与规范一致，因为无论如何都没有发送邮件正文，但它与第一个发送值的示例非常不一致。客户端无法知道索引文件是HTML还是PHP，所以看起来有时会发送一个值似乎很奇怪。
所以，我同意这个规范与自己相矛盾，显然，Apache也是如此。如果您正在设计一个HTTP库，我建议您尽可能地使用它来处理您可能遇到的各种消息，即使它们并非完全符合规范。
答案 1 :(得分：0)
RFC 2616已过时。新规范中的描述已完全重写。请参阅http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-26.html#message.body.length。