Content-Length is used to describe the transfer-length of the message-body. In the HTTP protocol, there is a difference between the length of the message entity and the transmission length of the message entity, 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 specific HTTP interactions, how the client obtains the message length is 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 preferred to find the corresponding length. For example, the Chunked model.
"If there is a Content-Length in the head, then this Content-Length represents both the body length and the transmission length. If the entity length and transfer length are not equal (e.g. Transfer-Encoding is set), then the Content-Length cannot be set.If Transfer-Encoding is set, then Content-Length will be ignored”。 The advantage of this sentence translation is that there is only one point: with Transfer-Encoding, there can be no Content-Length.
Range transmission. I didn't pay attention, I didn't read it in detail :)
Closing the connection through the server determines the length of the message being transmitted. (The requester cannot indicate the end of the request body by closing the connection, as this would leave the server with no chance to continue responding.) This situation mainly corresponds to short connections, i.e. non-keep-alive mode.
HTTP 1.1 must support chunk mode. Because when the length of the message is uncertain, this situation can be handled through the chunk mechanism.
In the header containing the message content, if there is a content-length field, the corresponding value of the field must exactly match the length of the message topic.
“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
That isIf there is a chunk, there can be no content-length 。
The persistent connection mechanism of HTTP/1.0 was introduced later, and it is implemented through the header Connection: keep-alive, which can be used by both the server and the client to tell each other that they do not need to disconnect the TCP connection after sending the data for later use.HTTP/1.1 requires that all connections be persistent，Unless you explicitly add Connection: close to the header。 So in fact, the Connection header field in HTTP/1.1 no longer has the value of keep-alive, but due to historical reasons, many web servers and browsers still retain the habit of sending Connection: keep-alive to HTTP/1.1 long connections.
In fact, the last few can be almost ignored, and a brief summary is as follows:
1. Content-Length: If it exists and is valid, it must be exactly the same as the transmission length of the message content. (Tested to truncate if too short, and too long to cause a 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 transmission length of the message can be determined directly by closing the connection through the server. (This is easy to understand)
Combined with other features of the HTTP protocol, for example, Http1.1 did not support keep alive. Then the following conclusions can be drawn:
1. In Http 1.0 and earlier versions, the content-length field is optional.
2. In http1.1 and later versions. If you keep alive, then content-length and chunk must be one of the two. If it is not keep alive, it is the same as http1.0. content-length.
|
Posted on 9/24/2019 3:53:29 PM
|
|
|
