怎样判断已经接收完HTTP客户端的请求数据？解决方案
怎样判断已经接收完HTTP客户端的请求数据？
就是我不停的收，问题是不知道客户端的数据发完了没有？怎样判断？另外，就是当接收完后，向客户端发送数据，客户端又怎样知道服务器端发送完响应数据呢？
------解决方案--------------------
看RFC2616文档4.4节。
4.4 消息的长度（Message Length）
当消息主体出现在消息中时，一条消息的传输长度（transfer-length）是消息主体（messagebody）
的长度；也就是说在实体主体被应用了传输编码（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）。Content-
Length 头域不能包含在消息中，如果实体主体长度（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）当接收了一个
无效的长度时必须能通知用户。
就是我不停的收，问题是不知道客户端的数据发完了没有？怎样判断？另外，就是当接收完后，向客户端发送数据，客户端又怎样知道服务器端发送完响应数据呢？
------解决方案--------------------
看RFC2616文档4.4节。
4.4 消息的长度（Message Length）
当消息主体出现在消息中时，一条消息的传输长度（transfer-length）是消息主体（messagebody）
的长度；也就是说在实体主体被应用了传输编码（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）。Content-
Length 头域不能包含在消息中，如果实体主体长度（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）当接收了一个
无效的长度时必须能通知用户。