httpclient-4.5.9.jar
org.apache.http:
auth identity
client end
conn connection
Local cookie
impl: realization
execchain abnormal
httpcore-4.4.11.jar
org.apache.http.entity;
AbstractHttpEntity
body http request packet message format:
Content-Type: message type: application / json; charset = utf-8
Content-Encoding: encoding: gzip or deflate
Content-Length: packet length:
Chunked: whether the transmission block
Content-Length, HTTP message length, number of octets represented by decimal numbers. In general, a lot of work have been completed framework, we rarely pay attention to this part, but it happened a few cases Content-Lengthinconsistent with the actual length of the message, the program rather strange exception may occur, such as:
- No response until a timeout.
- Request is truncated, and the next request appears resolve confusion.
Content-LengthIs the HTTP message length, number of octets indicated by decimal numbers, Headers is a common field. Content-LengthIt should be accurate, which would otherwise cause an exception (in particular, in this field, HTTP1.0 is optional) .
Content-LengthThe header indicates the entity body of the message bytes in size. This size is inclusive of all content encoding, for example, the text file was gzipcompressed, then Content-Lengththe first part refers to the size of the compressed instead of the original size.
How Content-Length works
Content-LengthUsing a digital representation of the decimal length, message server / client through which the message is to be read that follow.
If this length is incorrect, the following happens:
Content-Length> actual length
If the Content-Length is greater than the actual length, the server / client message read to the end, wait for the next byte will, naturally no response until the timeout.
Similarly, in a response message Content-Lengththan the actual length of the effect is the same:
Content-Length <actual length
If the length is less than the actual length, the first request message is intercepted, such as parameters param=piaoruiqing, Content-Lengthis 10, then the request message will be truncated to: param=piaoas shown:
But, just so we, of course not, we look at the second request what makes unexpected things will happen, as shown:
Two consecutive requests, the first message was cut off, while the second is not expected truncation occurs, but the server throws an exception: Request method 'ruiqingPOST' not supported. Thorn does not irritate (Techno)゚Д゚()
That ruiqingPOSTis what the fairy method ??? At this point, with many years of development sensitivity (DEBUG) the experience acquired, we can roughly guess, the last time the request is intercepted rest of the news appeared in the request. Out wireshark to verify, as shown:
Reasons for this is opened Connection:keep-alive, if used Connection:close, the resulting phenomenon is that every time the requests are cut off, but does not produce (such as the message will last the rest of the stitching to the subsequent request message) to resolve the confusion.
Content-Length value unsure of how to do
Content-Length首部指示出报文中实体主体的字节大小. 但如在请求处理完成前无法获取消息长度, 我们就无法明确指定Content-Length, 此时应该使用Transfer-Encoding: chunked
什么是Transfer-Encoding: chunked
数据以一系列分块的形式进行发送. Content-Length 首部在这种情况下不被发送. 在每一个分块的开头需要添加当前分块的长度, 以十六进制的形式表示，后面紧跟着 \r\n , 之后是分块本身, 后面也是\r\n. 终止块是一个常规的分块, 不同之处在于其长度为0.
Transfer-Encoding: chunked是如何工作的
接下来我们用一个下载文件的例子, 来探讨Transfer-Encoding: chunked是如何工作的. 服务端代码如下:
使用postman发起请求, wireshark抓包查看, 如图:
在wireshark中可以很清晰地看到chunked的数据, 其结构大致是: 返回的消息被分为多个数据块, 每个数据块有两部分, 长度 + 数据, 这两部分都以CRLF(即\r\n)结尾. 而终止块是一个特殊的数据块, 其长度为0, 如图:
如此, 即完成了分块编码. 其主要应用于如下场景, 即要传输大量的数据, 但是在请求在没有被处理完之前响应的长度是无法获得的. 例如, 当需要用从数据库中查询获得的数据生成一个大的HTML表格、需要传输大量的图片等.
Content-Length如果存在且生效, 必须是正确的, 否则会发生异常.(大于实际值会超时, 小于实际值会截断并可能导致后续的数据解析混乱)- 如果报文中包含
Transfer-Encoding: chunked首部, 那么Content-Length将被忽略. - @转自：https://blog.piaoruiqing.com.