- 由状态码决定的没有消息体的请求(1XX,204,304),那么接受到请求头后则结束。
- Transfer-Encoding为chunked的时候,接受到一个长度为0的chunked
- Content-Length描述body长度,但是如果有transfer-length那么这个头就会被忽略,因为这样的话就是使用了以上第二种的方式
- 关闭链接
总结:
可以理解为判断是否结束为判断是否读取完整个请求
-> 是否拥有请求体,有点的话
-> 判断请求体大小判断
-> 静态判断利用Content-Length
-> 动态判断利用Transfer-Encoding为chunked
-> 判断请求是否结束
参见HTTP1.1标准协议内容
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节)出现,并且它的域值不是”identity”,那么传输长度(transfer-length)被“块”传输编码定义,除非消息因为关闭连接而被终结了。
3。如果Content-Length头域(属于实体头域)(见14.13节)出现,那么它的十进制值(以字节表示)就代表实体主体长度(entity-length,译注:实体长度其实就是实体主体的长度,以后把entity-length翻译成实体主体的长度)也代表传输长度(transfer-length)。Content-Length头域不能包含在消息中,如果实体主体长度(entity-length)和传输长度(transfer-length)两者不相等(也就是说,消息里应用了传输译码(Transfer-Encoding)头域)。如果一个消息即有传输译码(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用户代理必须通知用户当一个无效的长度接收了。
注意事项:
- 注意区分内容结束跟内容没多大关系,比如form表单里面boundary是消息体里面内容,虽然最后一个boundary表示表单结束,但是针对一个HTTP请求来说,并不知道后面还会不会有boundary。