不在服务器响应中包含内容长度标头的后果是什么？ [英] What are the consequences of not including a content-length header in a server response?
问题描述
RFC 说 content-length header是可选的（..Applications应该使用此字段......）。
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?
推荐答案
我认为您的隐含问题是客户端如何检测HTTP消息的结束？。请参阅 RFC 7230 - HTTP / 1.1消息语法和路由 - 消息体长：
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):
-
对HEAD请求的任何回复以及1xx
（信息），204（无内容）的任何回复，或者304（未修改）状态
代码始终由
头字段后的第一个空行终止，无论
消息中是否存在头字段，因此不能包含消息正文。
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.
对CONNECT请求的任何2xx（成功）响应意味着
连接将在空的
行之后立即成为隧道总结标题字段。客户端必须忽略
中收到的任何
Content-Length或Transfer-Encoding标头字段这样的消息。
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.
如果转移 - 存在编码头字段，并且分块的
传输编码（第4.1节）是最终编码，消息
主体长度通过读取和解码分块的
数据来确定，直到传输编码指示数据已完成。
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.
如果响应中存在Transfer-Encoding标头字段且
，则分块传输编码不是最终编码，
消息体长度是通过读取连接确定的，直到服务器关闭
。如果请求中存在Transfer-Encoding头字段
，并且分块传输编码不是
最终编码，则无法确定消息体长度
;服务器必须使用400（错误请求）
状态代码进行响应，然后关闭连接。
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.
如果收到包含Transfer-Encoding和一个
Content-Length头字段，Transfer-Encoding会覆盖
Content-Length。这样的消息可能表示尝试
执行请求走私（第9.5节）或响应拆分
（第9.4节）并且应该作为错误处理。发送方必须
删除收到的Content-Length字段，然后转发下游的
a消息。
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.
如果收到的消息没有转移-Encoding并且
具有不同
字段值的多个Content-Length头字段或具有
无效值的单个Content-Length头字段，则消息框架无效且
收件人必须将其视为不可恢复的错误。如果这是
请求消息，则服务器必须使用400（错误请求）
状态代码进行响应，然后关闭连接。如果这是代理收到的响应
消息，代理必须关闭连接
到服务器，丢弃收到的响应，并向客户端发送502（Bad
Gateway）响应。如果这是用户代理收到的响应消息
，则用户代理必须关闭与服务器的
连接，并丢弃收到的响应。
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.
如果存在有效的Content-Length头字段而没有
Transfer-Encoding，则其十进制值以八位字节定义预期消息
体长。如果发件人关闭连接或
收件人在指定的八位字节数收到
之前超时，收件人必须认为邮件是
不完整并关闭连接。
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.
如果这是一条请求消息而且以上都不是真的，那么
消息体长度为零（不存在消息体）。
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).
否则，这是一条没有声明消息
体长的响应消息，因此消息体长度由收到的
八位字节数确定在服务器关闭
连接之前。
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.
所以回答你的问题：方案3（分块）和7（读取直到服务器关闭连接）是客户端不知道长度的那些事先。
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屋！
