检测HTTP请求正文的结束

Question

我正在编写自己的HTTP客户端和服务器,并希望客户端在请求中包含一个可选的主体.在服务器端,我想在发送HTTP响应之前读取整个主体.我的问题是在服务器上我怎么知道我已经阅读了整个身体？

即使在这种情况下我控制客户端和服务器,我正在寻找一种"标准"方法.但是,由于Content-Length是可选的,我想要一个不需要它的方法.如果客户端关闭连接,则很容易读取所有可用数据,但客户端需要保持连接打开以等待响应,因此此方法不起作用.

我能想到的只有身体的格式和检测终结者(例如</HTML>).理想情况下,我不想要那些知识.

我有一种方法可以忽略吗？

Answer 1

假设您希望您的客户端与其他服务器一起工作,并且服务器与其他客户端一起工作,那么您的服务器就不能期望得到很好的处理.

有两种方法可以判断身体何时结束.他们都不需要像你建议的那样需要知道身体的内容类型(例如,不要费心寻找</html>- 远远超出HTTP协议).

1. 如果客户端发送消息Transfer-Encoding: Chunked,则需要解析稍微复杂的分块传输编码语法.你真的没有多少选择 - 如果客户端以这种格式发送,你必须收到它.当客户端使用此方法时,您可以通过长度为0的块检测正文的结尾.
2. 如果客户端改为发送Content-Length,则必须使用它.

正如您所建议的,检测结束的第三种方法 - 连接关闭时 - 仅适用于响应,而不是请求(因为没有办法发送响应).

Answer 2

If a request contains a message-body and a Content-Length is not given, 
the server SHOULD respond with 400 (bad request) if it cannot determine
the length of the message, or with 411 (length required) if it wishes 
to insist on receiving a valid Content-Length.

即你有权坚持任何一个Transfer-Encoding: chunked或者Content-Length,所以你不必担心在任何其他情况下确定长度

Answer 3

我添加另一个答案主要是因为我没有足够的代表评论mgiuca的.我知道这个问题有点旧,但没有明确的答案.

至于有人提到,考虑到主要的事情是,你的服务器无法控制他人互动,这意味着你可以不知道他们会派所有,且必须准备处理任何通过该门来.考虑到这一点,坚持标准和常规做法可能是最好的选择.

如果客户端发送"Content-Length"标头,则服务器必须解析它并使用它来确定请求的结束.如果没有这样的标题但是存在"Transfer-Encoding:chunked"标题,则服务器必须能够解析分块请求(来自mgiuca的答案的链接).最后,如果两者都不存在,"连接结束"表示请求结束.

我认为您忽略的是客户端可以结束连接并仍然从服务器获得响应.我的意思是,"结束连接"是什么意思？请记住,HTTP是一种通常通过TCP传输的应用层协议.探索TCP的功能(特别是其连接终止协议)揭示了一些有趣的信息:

• 为了主动结束连接,客户端发送带有FIN标志的数据包,这是四次握手的一部分.该连接仍被认为是开放的,因为终止协议尚未完成.
• 服务器接收该数据包并通知客户端(ACK包).服务器现在知道客户端将不再传输数据.
• 客户端进入FIN_WAIT2状态,等待来自服务器的带有FIN标志的数据包正确关闭连接.

但它确实存在!客户端已经通知他想要结束连接,并且服务器知道这一点,但是连接仍然在客户端打开(他没有关闭它,因为他没有收到FIN数据包).服务器现在应答请求,然后正确关闭连接.值得注意的是,客户端将是非常重要的ACK每个服务器数据包与附加RST标志,告诉他仍在等待服务器FIN关闭连接.

当服务器完成时(在我们的小例子中,在发送HTTP响应之后),他关闭了他身边的连接,发送了FIN数据包.客户收到它时会关闭他的一方,并通过ACK通知服务器.

另外请注意,我不知道您正在编程的上下文,但大多数时候您最终会在套接字上调用shutdown().POSIX的关闭(至少是Windows)将要关闭的连接接口作为函数参数.这些规范清楚地表明您可以关闭发件人部分(这正是客户端将要执行的操作),禁用数据发送,同时允许客户端接收更多数据.

关于TCP连接的更多细节超出了这个问题的范围,但我建议阅读它以更好地理解使用它的更高层的协议.

Answer 4

RFC

简单方法:使用HTTP 1.0并要求内容长度

为了与HTTP/1.0应用程序兼容,包含消息体的HTTP/1.1请求必须包含有效的Content-Length头字段,除非已知服务器符合HTTP/1.1.如果一个请求包含一个消息体并且没有给出Content-Length,那么服务器应该响应400(错误的请求),如果它不能确定消息的长度,或者如果它希望坚持,则应该使用411(需要的长度)收到有效的内容长度.

Answer 5

我认为当您说“内容长度是可选的”时，您正在阻止自己使用最明显的选择。

来自 HTTP 规范：http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

应用程序应该使用此字段来指示消息主体的传输长度，除非第 4.4 节中的规则禁止这样做。

如果您知道长度（听起来您会知道），请在 Content-Length 标头中指定它并完成它，因为规范基本上要求您这样做（假设您所做的任何其他事情都没有违反 http:// 中提到的规则） /www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4）。