为什么有些服务器在最后一个块长度为零后不使用 CRLF？

Question

我正在使用 HTTP 请求工具（类似于 cURL）并且遇到服务器响应问题。或者我对 HTTP 1.1 和分块数据的 RFC 的理解。

我所看到的是分块数据应采用以下格式：

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0\r\n
\r\n

我实际看到的是以下内容：

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0

换句话说，我测试过的少数服务器在 0.. 之后不再发送数据。不是 CRLF，更不用说 CRLFCRLF。

如果没有正确的分块标签格式，我们怎么知道这是分块数据的结尾？超时发生在 0 之后寻找 CRLF，这还不够。

Answer 1

使用内容长度，绝对是我知道的时候；对于文件下载，检查文件大小对于资源而言无关紧要。对于分块传输，我们不会扫描消息正文中的 CRLF 对。它首先读取指定数量的字节，然后再读取两个字节以确认它们是 CR 和 LF。如果不是，则消息正文格式不正确，并且大小指定不正确或数据已损坏。

欲了解更多信息，请阅读RCF，其中说

在响应中使用分块传输编码的服务器不得将尾部用于任何标头字段，除非至少满足以下条件之一：

a) 请求包含一个 TE 头字段，指示“预告片”在响应的传输编码中是可接受的，如第 14.39 节所述；或者，

b) 服务器是响应的源服务器，尾部字段完全由可选元数据组成，接收者可以使用该消息（以源服务器可接受的方式）而不接收此元数据。换句话说，源服务器愿意接受尾部字段可能在通往客户端的路径上被默默丢弃的可能性。

确定消息正文长度的方法：

如果 header 有 Transfer-Encoding 并且分块传输是最终编码，则通过读取和解码分块数据来确定消息正文长度，直到传输编码指示数据完整。

如果标头具有 Transfer-Encoding 并且分块传输不是最终编码，则通过读取连接来确定消息正文长度，直到服务器关闭该连接。

如果请求头中有 Transfer-Encoding，并且分块传输不是最终编码，则无法可靠地确定消息正文长度；服务器必须响应 400（错误请求）状态代码，然后关闭连接。

如果收到的消息同时带有 Transfer-Encoding 和 Content-Length 标头字段，则 Transfer-Encoding 会覆盖 Content-Length。此类消息可能表明尝试执行请求响应拆分，应将其作为错误处理。发送者必须在向下游转发此类消息之前删除收到的内容长度字段。