Interpretation of Content-Length in the Http Protocol

In the HTTP protocol, there is a detailed interpretation of Content-Length. Content-Length is used to describe the transfer length of the HTTP message entity. In the HTTP protocol, the length of the message entity and the transmission length of the message entity are different. For example, under gzip compression, the length of the message entity is the length before compression, and the transmission length of the message entity is the length after gzip compression. In the specific HTTP interaction, how does the client obtain the message length, mainly based on the following rules: If the response is 1xx, 204, 304 or head request, the message entity content is directly ignored. If there is Transfer-Encoding, the method in Transfer-Encoding is used first to find the corresponding length. For example, the Chunked mode. “ If there is Content-Length in the head, then this Content-Length represents both the length of the entity and the length of the transmission. If the entity length and the transfer length are not equal (for example, Transfer-Encoding is set), then Content-Length cannot be set. If Transfer-Encoding is set, Content-Length will be ignored. The advantage of this sentence translation is, in fact, the key point is: With Transfer-Encoding, there can be no Content-Length. Range transmission. Do not pay attention, did not read in detail :) The connection length can be determined by closing the connection through the server. (The requester cannot indicate the end of the request message body by closing the connection, as this will give the server no chance to continue responding). This situation mainly corresponds to a short connection, that is, a non-keep-alive mode. HTTP 1.1 must support chunk mode. Because when the length of the message is uncertain, this can be handled by the chunk mechanism. In the header containing the message content, if there is a content-length field, the value corresponding to the field must match the length in the message subject. "The entity-length of a message is the length of the message-body before any transfer-codings have been applied", that is, there is no content-length for chunks.

In fact, the following articles can almost be ignored, and the following is briefly summarized as follows: 1. If Content-Length exists and is valid, it must be exactly the same as the transmission length of the message content. (After testing, if it is too short, it will be truncated. If it is too long, it will cause timeout.) 2. If there is Transfer-Encoding (the focus is chunked), there can be no Content-Length in the header, and it will be ignored. 3. If a short connection is used, the connection length of the message can be determined directly by the server closing the connection. (This is easy to understand) Combined with other features of the HTTP protocol, for example, before the Http1.1 does not support keep alive. Then you can draw the following conclusions: 1. In Http 1.0 and earlier versions, the content-length field is optional. 2. In http1.1 and later versions. If it is keep alive, then content-length and chunk must be two. If it is non-keep alive, it is the same as http1.0. Content-length is optional.