如何通过关闭连接可靠地确定主体长度（RFC 2616 4.4.5）

Posted 2023-02-17

【中文标题】如何通过关闭连接可靠地确定主体长度（RFC 2616 4.4.5）

【英文标题】：How is determining body length by closing connection reliable (RFC 2616 4.4.5)

【发布时间】：2015-05-12 21:45:17

【问题描述】：

我无法弄清楚一件事。 RFC 2616 in 4.4.5 声明Message Length 可以确定为“By the server closing the connection.”。

这意味着，服务器响应（例如返回大图像）的响应是有效的，响应头中没有 Content-Length，但客户端应该继续获取 直到连接已关闭，然后假定所有数据都已下载。

但是客户端如何确定连接是由服务器故意关闭的呢？服务器应用程序可能在发送数据的过程中崩溃，服务器的操作系统很可能会发送FIN 数据包以正常关闭与客户端的 TCP 连接。

【问题讨论】：

你为什么要看 RFC 2616，顺便说一句？相关的在这里：greenbytes.de/tech/webdav/rfc7230.html#message.body.length>

因为大部分 Internet 仍然在 RFC 2616 上运行，因为 723x 仅在 11 个月前标准化。

@RemyLebeau - Julian Reschke 是 HTTP 的主要权威，所以他知道自己在说什么 :)“新”RFC 并不完全是一个新规范，它更像是一种澄清。

【参考方案1】：

您说的完全正确，这种机制完全不可靠。这在 RFC 7230 中有介绍：

由于没有办法区分是否成功完成， 来自部分接收消息的封闭分隔消息中断 由于网络故障，服务器应该生成编码或 尽可能使用长度分隔的消息。封闭的界线 该功能的存在主要是为了向后兼容 HTTP/1.0。

幸运的是，当今大多数 HTTP 流量都是 HTTP/1.1，使用 Content-Length 或“Transfer-Encoding”来明确定义消息的结尾。

教训是，消息必须有自己的终止方式；我们不能将底层传输层的 EOF 重新用作消息的 EOF。

就此而言，（格式良好的）html 文档或.gif、.avi 等确实定义了自己的终止；我们会知道我们是否收到了不完整的文件。因此，在没有 Content-Length 的情况下通过 HTTP/1.0 传输它并不是什么大问题。

但是，对于纯文本文档，javascript、css 等。EOF 用于标记文档的结尾，因此在 HTTP/1.0 上存在问题。