HTTP HEAD 方法和管道
我正在编写一些解析 HTTP 请求和响应的代码，但它可能无法看到每个对话的双方。
HTTP RFC 声明 HEAD 请求应该引起与 GET 完全相同的响应，只是不发送消息正文。这似乎意味着将包含 Content-Length 标头。
如果正在使用 HTTP 管道，我无法看到如何可靠地解析对管道的响应HEAD 没有看到请求；标头无法正确指示响应的长度，没有传输编码，并且连接不一定会在最后关闭。
有什么想法吗？任何人都可以看到在没有看到请求的情况下无法解析的任何其他类型的响应吗？
I'm writing some code that parses HTTP requests and responses, but it may not see both sides of every conversation.
The HTTP RFC states that a HEAD request should cause exactly the same response as GET except that a message body is not sent. This seems to imply that a Content-Length header would be included.
If HTTP Pipelining is being used, I cannot see how you would reliably parse a pipelined response to a HEAD without having seen the request; the headers would not correctly indicate the length of the response, there is no Transfer-Encoding, and the connection would not necessarily be closed at the end.
Any ideas? Can anyone see any other types of response that cannot be parsed without seeing the request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我同意。不可能知道对请求的响应没有实体主体，即使 ContentLength 标头似乎暗示着相反的情况。因此，所有实现都应考虑请求方法。
I agree. It is not possible to know that the response to the request does not have an entity body, even though the ContentLength header seems to imply the opposite. All implementations should take the request method into account for this reason.