在服务器响应中不包含内容长度标头的后果是什么？答案

【问题标题】：What are the consequences of not including a content-length header in a server response?在服务器响应中不包含内容长度标头的后果是什么？
【发布时间】：2015-01-29 10:55:57
【问题描述】：

RFC 表示content-length 标头是可选的（“..应用程序应该使用此字段...”）。

据我所知，如果不包括在内，那么客户端将不知道需要多少数据，因此在下载正文时将无法显示确定的进度条（即顶部栏而不是底部）。

是否存在因省略此标头而产生的任何其他副作用或错误？

【问题讨论】：

标签： http http-headers httpresponse content-length

【解决方案1】：

我认为您的隐含问题是“客户端如何检测 HTTP 消息的结尾？”。见RFC 7230 - HTTP/1.1 Message Syntax and Routing - Message Body Length：

消息正文的长度由以下之一确定（按优先顺序）：

对 HEAD 请求的任何响应以及任何带有 1xx 的响应（信息）、204（无内容）或 304（未修改）状态代码总是以第一个空行结束标头字段，无论标头字段存在于消息，因此不能包含消息正文。

对 CONNECT 请求的任何 2xx（成功）响应都意味着连接将在空后立即成为隧道结束标题字段的行。客户端必须忽略任何接收到的 Content-Length 或 Transfer-Encoding 标头字段这样的消息。

如果存在 Transfer-Encoding 标头字段并且分块传输编码（第 4.1 节）是最终的编码，即消息正文长度是通过读取和解码分块来确定的直到传输编码指示数据完成。

  If a Transfer-Encoding header field is present in a response and

   the chunked transfer coding is not the final encoding, the
   message body length is determined by reading the connection until
   it is closed by the server.  If a Transfer-Encoding header field
   is present in a request and the chunked transfer coding is not
   the final encoding, the message body length cannot be determined
   reliably; the server MUST respond with the 400 (Bad Request)
   status code and then close the connection.

  If a message is received with both a Transfer-Encoding and a

   Content-Length header field, the Transfer-Encoding overrides the
   Content-Length.  Such a message might indicate an attempt to
   perform request smuggling (Section 9.5) or response splitting
   (Section 9.4) and ought to be handled as an error.  A sender MUST
   remove the received Content-Length field prior to forwarding such
   a message downstream.

如果接收到的消息没有传输编码并且带有具有不同的多个 Content-Length 标头字段 field-values 或单个 Content-Length 标头字段，具有无效值，则消息帧无效并且收件人必须将其视为不可恢复的错误。如果这是一个请求消息，服务器必须响应 400（错误请求）状态码，然后关闭连接。如果这是回应代理收到消息，代理必须关闭连接到服务器，丢弃收到的响应，并发送一个 502 (Bad 网关）对客户端的响应。如果这是响应消息由用户代理接收，用户代理必须关闭连接到服务器并丢弃收到的响应。

如果存在有效的 Content-Length 标头字段，但没有 Transfer-Encoding，它的十进制值定义了预期的消息以八位字节为单位的体长。如果发件人关闭连接或收件人在指定的八位字节数之前超时收到，接收者必须认为该消息是不完整并关闭连接。

如果这是一条请求消息，并且以上都不是真的，那么消息体长度为零（不存在消息体）。

否则，这是一个没有声明消息的响应消息正文长度，因此消息正文长度由服务器关闭之前收到的八位字节数连接。

当服务器省略 content-length 标头时，它必须使用其他机制之一来指示消息的结束。

所以回答你的问题：场景 3（分块）和 7（读取直到服务器关闭连接）是客户端事先不知道长度的场景。

【讨论】：