4.4 消息的长度（Message Length）

当消息主体出现在消息中时，一条消息的传输长度（transfer-length）是消息主体（message-body）的长度；也就是说在实体主体被应用了传输编码（transfer-coding）后。当消息中出现消息主体时，消息主体的传输长度（transfer-length）由下面（以优先权的顺序）决定：: 

1。任何不能包含消息主体（message-body）的消息（这种消息如 1xx，204 和 304 响应和任 何 HEAD 方法请求的响应）总是被头域后的第一个空行（CRLF）终止，不管消息里是否存在实体头域（entity-header fields）。 

2。如果 Transfer-Encoding 头域（见 14.41 节）出现，并且它的域值是非”“dentity”传输编码 值，那么传输长度（transfer-length）被“块”（chunked）传输编码定义，除非消息因为通过关闭连接而结束。 

3。如果出现 Content-Length 头域（属于实体头域）（见 14.13 节），那么它的十进制值（以字节表示）即代表实体主体长度（entity-length，译注：实体长度其实就是实体主体的长度， 以后把 entity-length 翻译成实体主体的长度）又代表传输长度（transfer-length）。ContentLength 头域不能包含在消息中，如果实体主体长度（entity-length）和传输长度（transferlength）两者不相等（也就是说，出现 Transfer-Encodind 头域）。如果一个消息即存在传输译码（Transfer-Encoding）头域并且也 Content-Length 头域，后者会被忽略。 4。如果消息用到媒体类型“multipart/byteranges”，并且传输长度（transfer-length）另外也没有指定，那么这种自我定界的媒体类型定义了传输长度（transfer-length）。这种媒体类型不能被利用除非发送者知道接收者能怎样去解析它； HTTP1.1 客户端请求里如果出现 Range 头域并且带有多个字节范围（byte-range）指示符，这就意味着客户端能解析 multipart/byteranges响应。

一个 Range 请求头域可能会被一个不能理解 multipart/byteranges 的 HTTP1.0 代理（proxy）再次转发；在这种情况下，服务器必须能利用这节的 1，3 或 5 项里定义的方法去定界此消息。

5。通过服务器关闭连接能确定消息的传输长度。（请求端不能通过关闭连接来指明请求消息体的结束，因为这样可以让服务器没有机会继续给予响应）。 

为了与 HTTP/1.0 应用程序兼容，包含 HTTP/1.1 消息主体的请求必须包括一个有效的内容长 度（Content-Length）头域，除非服务器是 HTTP/1.1 遵循的。如果一个请求包含一个消息主体并且没有给出内容长度（Content-Length），那么服务器如果不能判断消息长度的话应该以400 响应（错误的请求），或者以 411 响应（要求长度）如果它坚持想要收到一个有效内容长 度（Content-length）。 

所有的能接收实体的 HTTP/1.1 应用程序必须能接受"chunked"的传输编码（3.6 节），因此当消息的长度不能被提前确定时，可以利用这种机制来处理消息。 

消息不能同时都包括内容长度（Content-Length）头域和非 identity 传输编码。如果消息包括了一个非 identity 的传输编码，内容长度（Content-Length）头域必须被忽略. 

当内容长度（Content-Length）头域出现在一个具有消息主体（message-body）的消息里，它的域值必须精确匹配消息主体里字节数量。HTTP/1.1 用户代理（user agents）当接收了一个无效的长度时必须能通知用户。