http - HTTP库是否可以在不了解请求方法的情况下确定消息正文的长度？

Question

在http请求/响应期间，如何确定消息体的存在和长度，特别是，所需的算法是否使用请求方法作为输入？
不过，我对请求和响应都感兴趣
this question asks about the requests's message-body's existance and length，并且它看起来应该可以单独在头上确定（即使用§4.4 of RFC2616中指定的方法），这对请求是有利的，但是对响应也可以这样做吗？
RFC2616 §4.4似乎表明应该对请求和响应使用相同的算法（因为它是用消息体的泛型术语来表示的），所以这似乎表明它可以泛型地完成。
然而，这里的HEAD method非常突出：内容长度在响应期间作为头的一部分发送回来，但是没有正文。
头部是特殊的，也是唯一特殊的方法吗？或者extension method可以有类似的行为，因此我确实需要知道每个方法是否需要特殊处理。（因此，除非在http之外预先协商，否则不能使用扩展方法。）

Answer 1

tl；dr-no-http库在不知道请求方法的情况下无法100%可靠地确定响应的消息体的存在，这与规范使用相同算法处理请求和响应的另一点相矛盾。
更新：正如@julianreschke提到的，规范的那一部分已经被重写。下面是我自己的实证证据来进一步佐证这一点。
§4.4详细说明了确定真正“消息长度”的许多因素，并列出了响应类型（1）比Content-length头（3）的值具有更高的“优先级”。特别是，它提到“对head请求的任何响应”都属于“不得”包含消息体的响应。因此，即使服务器发送了错误的头，客户端也应该知道根据响应类型忽略它。这一点似乎被严格地遵循（如下所示），所以关于对请求和响应使用相同算法的另一点似乎是不正确的。
事实上，我尝试用不同的head请求访问自己的apache服务器，得到了非常不同的结果，因为Content-length，vis-a-vis与请求的工作方式一致。以下是我发送的请求和得到的回复的相关部分
请求：HEAD /
回复：200 OK
内容长度：1639
我的web根目录包含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
接受编码：gzip，deflate
回复：301 Moved Permanently
内容长度：20
返回到HEAD，但请求gzip响应。这次我得到内容长度20，它是应用gzip编码后空响应的大小。这是一致的，但是没有实际发送20字节的gzip消息（可能是因为它是一个HEAD请求）！
请求：HEAD /someproject/
回复：200 OK
目录确实包含index.php，但与第一个返回index.html文件大小的示例不同，这里apache不希望执行php脚本来查找实际响应的内容长度，因此它将其视为0。这与规范是一致的，因为无论如何都不会发送消息体，但它与第一个发送值的示例极不一致。客户机无法知道索引文件是html还是php，因此有时只发送一个值似乎很奇怪。
所以，我同意这个规范自相矛盾，显然，apache也是如此。如果您正在设计一个http库，我建议您使它尽可能健壮地处理您可能遇到的所有类型的消息，即使它们不完全符合规范。