http – 在服务器响应中不包含内容长度标头会产生什么后果？

RFC说内容长度标题是可选的(“..Applications应该使用这个字段……”).

如果不包括在内,那么我可以收集到的内容然后客户端将不知道预期有多少数据,因此在下载主体时(即顶部条而不是底部)将无法显示确定的进度条.

省略此标题是否还有其他副作用或错误？

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

The length of a message body is determined by one of the following
(in order of precedence):

1. Any response to a HEAD request and any response with a 1xx
   (Informational), 204 (No Content), or 304 (Not Modified) status
   code is always terminated by the first empty line after the
   header fields, regardless of the header fields present in the
   message, and thus cannot contain a message body.

2. Any 2xx (Successful) response to a CONNECT request implies that
   the connection will become a tunnel immediately after the empty
   line that concludes the header fields. A client MUST ignore any
   Content-Length or Transfer-Encoding header fields received in
   such a message.

3. If a Transfer-Encoding header field is present and the chunked
   transfer coding (Section 4.1) is the final encoding, the message
   body length is determined by reading and decoding the chunked
   data until the transfer coding indicates the data is complete.

   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.

4. If a message is received without Transfer-Encoding and with
   either multiple Content-Length header fields having differing
   field-values or a single Content-Length header field having an
   invalid value, then the message framing is invalid and the
   recipient MUST treat it as an unrecoverable error. If this is a
   request message, the server MUST respond with a 400 (Bad Request)
   status code and then close the connection. If this is a response
   message received by a proxy, the proxy MUST close the connection
   to the server, discard the received response, and send a 502 (Bad
   Gateway) response to the client. If this is a response message
   received by a user agent, the user agent MUST close the
   connection to the server and discard the received response.

5. If a valid Content-Length header field is present without
   Transfer-Encoding, its decimal value defines the expected message
   body length in octets. If the sender closes the connection or
   the recipient times out before the indicated number of octets are
   received, the recipient MUST consider the message to be
   incomplete and close the connection.

6. If this is a request message and none of the above are true, then
   the message body length is zero (no message body is present).

7. Otherwise, this is a response message without a declared message
   body length, so the message body length is determined by the
   number of octets received prior to the server closing the
   connection.

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

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