Reprint: http://www.51testing.com /? Uid-390472-action-viewspace-itemid-233985
Two entity-header (entity-header) in HTTP 1.1 are directly related to encoding, namely content-encoding and transfer-encoding.
The content-encoding header indicates that the object has been encoded. content-encoding is a part of the entity corresponding to the request URL. for example, if the request URL is http: // host/image.png.gz, the content-encoding may be gzip. the content-encoding value is case-insensitive. Currently, Gzip, compress, deflate, and identity are included in the http1.1 standard.
Corresponds to the content-encoding header. The HTTP request contains an Accept-encoding header, which is used to indicate the user agent (generally a browser) which types of codes can be accepted. if this header does not exist in the HTTP request, the server can think that the user agent can accept any encoding type.
Next, we will focus on the description of transfer-encoding, which indicates the entity encoding to achieve safe transmission or data compression. The difference between transfer-encoding and content-encoding is as follows:
1. Transfer-encoding is only available during transmission, not the characteristics of the object corresponding to the request URL.
2. Transfer-encoding is a "Jump-to-jump" header, while content-encoding is an "end-to-end" header.
For example, the request URL is http: // host/abc.txt. When the server sends data, the file can be compressed using gzip to save bandwidth, the receiver sees that transfer-encoding is gzip, Which is decoded first before obtaining the Request Entity.
In addition, multiple encodings may be used for the same object at the same time. Therefore, the encoding sequence in the transfer-encoding header is very important. It represents the decoding sequence. similarly, the transfer-encoding value is case-insensitive. Currently, the http1.1 standard includes gzip, compress, deflate, identity, and chunked.
Transfer-encoding has a specific encoding type: chunked encoding. this encoding transmits the object in blocks and marks the length one by one until the length is 0, indicating that the transmission is complete. This encoding is particularly useful when the object length is unknown (for exampleDatabaseDynamically generated data ). http1.1 standard stipulates that chunked encoding must be used whenever transfer-encoding is used, and chunked must be the last encoding layer. any HTTP 1.1 Application must be able to process chunked encoding.
The request header corresponding to transfer-encoding is te, which mainly indicates the transfer-encoding type that the request initiator is willing to receive. if Te is null or does not exist, it indicates that the only accepted type is chunked.
OthersTransfer-encoding-related headers also include trailer, which is related to chunked encoding and will not be described in detail.
As the name suggests, Content-Length indicates the length of the transmitted object, in bytes (when the request method is head, it indicates the length to be sent, but it is not actually sent .). content-Length is greatly affected by transfer-encoding. As long as transfer-encoding is not an identity, the actual transfer length is determined by chunked in the encoding, and Content-Length is ignored even if it exists.
Length of the HTTP message body
There are message bodies and Entity bodies in HTTP. Simply put, the message body is an entity without transfer-encoding. After transfer-encoding is applied, the message body is the encoded entity, as follows:
Message Body = Transfer-encoding encode (entity body)
How to determine the length of the message body? The HTTP 1.1 Standard provides the following methods (sorted by priority ):
1. If the response status is 1xx/204/304 or the request method is head, the message body length is 0.
2. If a non-"Identity" transfer-encoding method is used, the length of the message body is determined by the "chunked" encoding, unless the message ends when the connection is closed.
3. If the "Content-Length" Object Header exists, the message length is the value.
3. If a message ends by closing the connection, the length of the message body is determined by the length received before closing. This is not applicable to the message body contained in the HTTP request.