2

我不能直截了当地说一件事。4.4.5 中的RFC 2616声明Message Length可以确定“ By the server closing the connection.”。

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

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

4

1 回答 1

3

你是绝对正确的，这种机制是完全不可靠的。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 上是有问题的。

于 2015-05-12T22:58:29.537 回答