在服务器响应中不包含内容长度标头的后果是什么? [英] What are the consequences of not including a content-length header in a server response?

问题描述

:

<块引用>

消息正文的长度由以下之一确定(按优先顺序):

<块引用>

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

<块引用>

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

<块引用>

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

<块引用>

 如果响应中存在 Transfer-Encoding 标头字段并且

 分块传输编码不是最终编码，消息体长度是通过读取连接来确定的，直到它被服务器关闭.如果传输编码头字段存在于请求中并且分块传输编码不存在最终编码，无法确定消息体长度可靠；服务器必须响应 400(错误请求)状态码，然后关闭连接.

<块引用>

 如果收到的消息同时带有 Transfer-Encoding 和

 Content-Length 头域，Transfer-Encoding 覆盖内容长度.这样的消息可能表明试图执行请求走私(第 9.5 节)或响应拆分(第 9.4 节)并且应该作为错误处理.发件人必须在转发此类之前删除收到的 Content-Length 字段下游消息.

<块引用>

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

<块引用>

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

<块引用>

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

<块引用>

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

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

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

The RFC says the content-length header is optional ("..Applications SHOULD use this field...").

From what I can gather if its not included then the client will not know how much data to expect, therefore will not be able to show a determinate progress bar when downloading the body (i.e. the top bar instead of the bottom).

Are there any other side effects or bugs that arise from omitting this header?

解决方案

I think your implicit question is "How does a client detect the end of an HTTP message?". See 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.

When the server omits the content-length header, it has to use one of the other mechanisms to indicate the end of the message.

So to answer your question: scenarios 3 (chunking) and 7 (reading until the server closes the connection) are the ones where the client doesn't know the length on beforehand.

这篇关于在服务器响应中不包含内容长度标头的后果是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！