http - 在服务器响应中不包含内容长度 header 的后果是什么？

Question

RFC表示 content-length header 是可选的(“..应用程序应该使用此字段...”)。

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

省略此 header 是否会产生任何其他副作用或错误？

Answer 1

我认为您隐含的问题是“客户端如何检测 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) statuscode is always terminated by the first empty line after theheader fields, regardless of the header fields present in themessage, and thus cannot contain a message body.

2. Any 2xx (Successful) response to a CONNECT request implies thatthe connection will become a tunnel immediately after the emptyline that concludes the header fields. A client MUST ignore anyContent-Length or Transfer-Encoding header fields received insuch a message.

3. If a Transfer-Encoding header field is present and the chunkedtransfer coding (Section 4.1) is the final encoding, the messagebody length is determined by reading and decoding the chunkeddata 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 witheither multiple Content-Length header fields having differingfield-values or a single Content-Length header field having aninvalid value, then the message framing is invalid and therecipient MUST treat it as an unrecoverable error. If this is arequest message, the server MUST respond with a 400 (Bad Request)status code and then close the connection. If this is a responsemessage received by a proxy, the proxy MUST close the connectionto the server, discard the received response, and send a 502 (BadGateway) response to the client. If this is a response messagereceived by a user agent, the user agent MUST close theconnection to the server and discard the received response.

5. If a valid Content-Length header field is present withoutTransfer-Encoding, its decimal value defines the expected messagebody length in octets. If the sender closes the connection orthe recipient times out before the indicated number of octets arereceived, the recipient MUST consider the message to beincomplete and close the connection.

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

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

当服务器省略内容长度 header 时，它必须使用其他机制之一来指示消息结束。

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