"HTTP authoritative guide" reading notes (vi)-entities and encodings

First, the entity header

The HTTP entity header describes the contents of the HTTP entry. The following 10 basic font header fields are defined in version http/1.1.

• Content-type: Types of objects that are hosted in an entity
• Content-length: The length or size of the transferred entity
• Content-language: The human language that best matches the transmitted object
• Content-encoding: Arbitrary transformations made by object data (for example, compression)
• Content-location: An alternate location through which the object can be obtained upon request
• Content-range: If this is a partial entity, this header indicates which part of the whole
• CONTENT-MD5: Entity body content and inspection and
• Last-modified: The transferred content was created on the server or last modified date time
• Expires: Date time when the Entity data will be invalidated
• Allow: the various request methods allowed by this resource, such as Get and head
• ETag: Document-specific unique verification code
• Cache-control: Indicates how the document should be cached

Second, Content coding

The process of content encoding is as follows:

1, the website server generates the original response message, which has the original Content-type and Content-length header

2. The Content encoding server (which may also be the original server or the downstream agent) creates the encoded message. The encoded message has the same content-type, but the content-length may be different (for example, the body is compressed). The content encoding server adds the content-encoding header to the encoded message so that the receiving application can decode it.

3, the receiving program obtains the encoded message, decodes, obtains the original message.

Commonly used content encoding types are: gzip (most efficient), compress, deflate, identity (the first three are lossless compression, will not result in loss of information)

At the same time, in order to avoid the server using the encoding method that the client does not support, the client puts the list of content encoding that it supports in the request accept-encoding header. If the client HTTP request does not have a accept-encoding header, then the server can assume that the client can accept any encoding (equivalent to sending accept-encoding:*)

The client can give each encoding a Q (mass) value parameter to describe the priority of the encoding. The Q values range from 0.0 to 1.0, and 0.1 indicates that the client does not want to accept the encoded encoding, and 1.0 represents the encoding that you want to use most. * denotes any other method.

Third, transmission coding and chunked coding

The HTTP protocol only defines the following two headers to describe and control the transmission encoding.

Transfer-encoding: Tell the receiver what encoding it has been given in order to reliably transmit the message.

TE: Used in the request header to tell the server which transport encoding extensions can be used.

The latest HTTP specification defines only one transfer encoding: chunked encoding

chunked coding

The chunked code divides the message into several known chunks of size. The blocks are sent next to each other, so that you do not need to know the size of the entire message before sending it. It is a transmission encoding and therefore a property of the message, not a stylistic one.

Trailer for chunking: Trailer can contain the accompanying header fields whose values may not be deterministic at the beginning of the message (for example, the content of the subject must be generated first). The CONTENT-MD5 header is a header that can be sent in a trailer because it is difficult to figure out the MD5 of a document before it is generated.

Iv. Scope of requests

Let's say you're downloading the latest hot movie from a slow modem, and you've downloaded three-fourths, and suddenly it's a bad thing to be forced to start all over again because a network failure connection is interrupted.

With a scope request, the HTTP client can resume downloading the entity by requesting a range (part of) of the entity that has failed. Of course, there is a premise that the client last requested the entity to the time of the request for the scope of this issue, the object has not changed. Example: range:bytes=4000-(starting from the section after 4000 bytes)

Not all servers accept range requests, but many servers can. The server can explain acceptable range requests to the client by including the Accept-ranges header in the response, which is usually measured in bytes.

The range header popularity is widely used in peer to peer file sharing client software, where they download different parts of the multimedia file from different peer entities at the same time.

Iv.. Differential coding

If the server has an instance of a page update, the full new page instance is sent to the client when the client requests the expired copy, even if only a small part of the page has changed. If there is less change, instead of sending a complete new page to the client, the client would prefer the server to send only the part of the page that changed, so that the most recent page can be obtained faster. Differential encoding is an extension of the HTTP protocol that optimizes transmission performance by exchanging portions of objects that change instead of the complete object.

If the client wants to tell the server that it is willing to accept the difference of the page, just send the A-im header. A-im is an abbreviation for accept-instance-manipulation (accepting instance manipulation). The server sends back the following: A special response code--226 IM used tells the client that it is sending an instance manipulation of the requested object, not the complete object itself; An IM header that describes the algorithm used to calculate the difference, the new ETag header and the delta-base header , which describes the etag of the baseline document used to calculate the variance, the entire process is accomplished by the instance manipulation, the diff generator, and the diff application.

ETag: Sent by the server in response, the client can use it in subsequent requests.

If-none-match: The client sends the request header and requests the document to the server only if the client's document version is not the same as the server.

A-im: Client request header, description of acceptable instance manipulation types

IM: Server response header, which describes the type of instance manipulation that acts on the response. This header is sent when the response code is 226 IM used.

Delta-base: Server response header, stating the ETag value of the baseline document used to calculate the variance (should be the same as the ETag in the If-none-match header in the client request)

"HTTP authoritative guide" reading notes (vi)-entities and encodings