【发布时间】：2015-05-20 03:43:35
【问题描述】：
如果对 GET 请求的响应没有 Content-Length 或 Transfer-encoding: chunked 字段，会发生什么？客户端如何知道消息何时结束？
【问题讨论】：
标签： http http-headers
【发布时间】：2015-05-20 03:43:35
【问题描述】：
RFC 7230 section 3.3.3 包含一个很好的查找消息正文大小的条件清单。本质上它说答案取决于状态代码是什么。相关条件为#1 和#7。
"1. 任何响应...带有 1xx （信息）、204（无内容）或 304（未修改）状态 代码总是以第一个空行结束 标头字段，无论标头字段存在于 消息，因此不能包含消息正文。”
"7. 否则，这是一个没有声明消息的响应消息 正文长度，因此消息正文长度由 服务器关闭之前收到的八位字节数 连接。”
同样值得知道的是，消息可能会在正文部分结束后继续。 RFC 7230 section 4.4 定义了一个 Trailers 功能，其中有效负载后面可以跟第二组 mime 标头。如果这些存在，则消息在它们所在的位置结束。
【讨论】：
-
值得注意的是，Trailer 仅针对
Transfer-Encoding: chunked（4.4 节仅描述Trailers标头；实际传输尾随数据的方法在 4.1.2 Chunked Trailer Part 中定义）。但是，在这种情况下，上面的第 7 点不适用，而是由分块传输编码（同一列表中的第 3 点）确定长度。 -
没有。分块编码预告片是一种不同类型的预告片，它们嵌入在每个块中，因此嵌入到正文部分中。第 4.4 节中的 HTTP Trailers 机制是 mime 标头，将整个消息作为后缀 - 在正文部分之外，并且不依赖于分块编码的使用。
-
哎呀，我的意思是“包含”而不是“是”。分块和非分块预告片都使用标头指示。即使只使用 content-length，非分块预告片也可以跟随正文。
-
你有参考吗？ 4.4 说“当消息包含使用分块传输编码编码的消息正文时”
根据规范
消息正文的长度由以下之一确定（在 优先顺序）：
- [...]
- 否则，这是一条没有声明消息正文长度的响应消息，因此消息正文长度由服务器关闭连接之前接收到的八位字节数决定。
客户端需要检测连接是否关闭。
【讨论】：
-
规格错误；它已被 RFC 7230 废弃，但在其他方面是正确的。