消息体长度有下列之一决定（按顺序优先）：
任何HEAD请求的响应，以及状态码为1xx（信息），204（无内容），或者304（未修改）的响应而不管消息中的头字段的出现，它们总是在头部分的第一个空行以后终止，因此不能包含消息体。
任何CONNECT请求的2xx响应（成功）在一个结束头字段的空行之后暗示连接将马上变为一个隧道。客户端必须忽略接收到的消息中的任何Content-Length或者Transfer-Encoding头字段。
如果出现了Transfer-Encoding头字段并且分块传输编码（4.1节）时最后的编码，消息的长度通过读取并解码分块数据决定，直到传输编码指示数据已经完整。
如果一个Transfer-Encoding头字段出现在响应中，并且分块传输编码不是最后的编码，那么消息体的长度通过读取数据决定，直到服务器关闭连接。
如果接收到的消息包含了Transfer-Encoding和Content-Length头字段，那么Transfer-Encoding将覆盖Content-Length。这样的消息可能表示试图执行请求走私（第9.5节）或响应分裂（第9.4节），应当作为错误处理。发送者必须在将该消息转发到下游之前移除接收到的Content-Length字段。
如果接收到的消息没有Transfer-Encoding，并带有多个具有不同字段值的Content-Lenght头字段，或者带有一个无效值的单个Content-Length头字段，那么消息的构成是无效的，接收者必须将其视为一个不可恢复的错误。如果这是一个请求消息，服务器必须响应一个400（坏请求）状态码并关闭连接。如果这是一个有代理接收的响应消息，代理必须关闭到服务器的连接，丢弃接收到的响应，并且给客户端发送一个502（坏网关）的响应。如果这是一个用户代理接收的响应消息，用户代理必须关闭到服务器的连接，并且丢弃接收到的消息。
如果有有效的Content-Length头字段而没有Transfer-Encoding，它的十进制数值定义了预期的消息体长度的字节数。如果发送者关闭了连接或者接收者在指示的字节数被接收到之前超时，接收者必须将消息视为不完整的并关闭连接。
如果一条消息不满足上述情况，那么消息体的长度是0（将没有消息体出现）。
否则，这将是一条没有声明消息长度的消息，所以消息体长度由在服务器关闭连接之前接收到的八位字节数决定。
由于没有办法从因网络故障终端而接收到的部分消息中区分成功完成，服务器应该尽可能生成编码或长度分隔的消息。关闭分隔功能主要是为了向下兼容HTTP / 1.0。
服务器可能以一个411（需要长度）响应来拒绝包含消息体但没有Content-Length的请求。
除非应用了一种不是分块的传输编码，发送包含消息体的请求的客户端如果预先直到消息体的长度，应该使用一个有效的Content-Length头字段，而不是分块传输编码，因为一些已经存在的服务器会以411（需要长度）状态码响应分块，虽然他们理解分块传输编码。这通常是因为这些服务是通过一个网关实现的，该网关在被调用之前需要一个内容长度，并且服务器在处理之前不能或不愿意缓冲整个请求。
用户代理如果不知道服务器能够处理HTTP/1.1（或之后的版本）的请求，那么发送一个包含消息体的请求必须发送一个有效的Content-Length头字段；这种知晓的形式可能是具体的用户配置或者通过先前接收的响应的版本的记忆。
如果连接的最后一个请求的最终响应已被完全接收，并且还有其他数据要读取，用户代理可能丢弃剩余的数据或尝试确定那部分数据是否术语先前响应体的一部分，如果先前消息的Content-Length值不正确，则可能是这种情况。客户端不得以分离的响应处理、缓存或转发这些额外数据，因为这样的行为很容易导致缓存污染。
若有收获，就点个赞吧
0 人点赞
