HTTP protocol Cache-control Header--Performance AH

Original address: http://tools.ietf.org/html/rfc2616#section-14.9

Content of this article

Overview
Terms
HTTP Cache-control Header
Resources that can be cached
Resources that can be stored in cache
Modify the basic expiration mechanism
Cache re-authentication and reload control
No-transform directive
Cache control Extensions
Resources

Overview
Recently done the project using Ext.net, because before looking at a lot of articles to improve the performance of the site, this kind of article mostly tend to theory, or engineering practice, are few words, can only sense, not an intuitive understanding. A lot of things are on their own.

Starting to focus on the performance problem stems from a project I made at the beginning of my graduation when I had no experience, just writing code, functional and design-oriented, without considering performance issues at all. Another part of the problem was the fact that many of the implementation details of WEB applications were not well understood at the time. Know why and what, but don't know how.

During this time, there was nothing to do, for the Ext.net Web application used Web page testing and statistical tools, such as HttpWatch, YSLOW and other tools to carry out some tests. These tests took me a lot of time, but it was a huge gain.

This article addresses caching issues with HTTP header Cache-control. Before the web and MSDN search, did not find a few about the Cache-control head of the possible assignment, and then go directly to the RFC documents, only to see the enlightened.

The following is a section of the RFC 2616 documentation on Cache-control, which provides clear definitions for some modal words, such as "must", "must not", and terminology. This text is too many, also not easy to translate. Because the RFC document focuses on theory, the concepts used are much broader than usual. For example, the entity can cover a lot of things, pages, CSS, scripts, images and so on can be considered as entities, but this article treats them as entities, and the body after the packaging is called entity. In addition to the entity, the entity is distinguished, the entity is part of the entity, it can be regarded as the content of the entity, the information concept is more focused on the contents of the HTTP protocol, in addition, the server (server) and the source server (Origin server) are distinguished.

Terms
The following are the terms that are required in this article (RFC 2616 documentation and other terminology). Would not have been listed, but it is necessary to think about it--to understand a thing, the first is to distinguish the concept.

Messages (Message)
The basic unit of HTTP communication, which consists of a structured octal sequence consisting of a message header, a message body, a message length, a generic message header domain, and so on (see Section 4 of RFC 2616) and transmission over the network.

Requests (Request)
An HTTP request message.

Response (response)
An HTTP response message.

Resources (Resource)
A network data object or service that can be identified by the URI (Uniform Resource Identifier) (see section 3.2 of RFC 2616). Resources can be presented in a reliable manner (for example, multiple languages, data formats, sizes, and parsing), or other changes.

Entities (Entity)

The information is transmitted as a request or response Payload (payload). An entity consists of meta-information in the form of entity header fields and content in the form of entities.

Entity is the HTTP protocol, the Entity header field (Entity-header fields) is the HTTP header, and the entity (entity-body) is the HTTP body.

Payload means, usually in the transmission of data, in order to make data transmission more reliable, to the original data in batches, and in each batch of data and the head and tail of a certain auxiliary information, such as the size of the batch of data, check the bit, so that the original data packaging, so that the original data is not easy to lose, The basic transmission unit in the transmission channel is formed--data frame or packet. The raw data in these data frames is the payload data.

Clients (client)
A program that establishes a connection for sending requests.

Users agent (user agents)
Initializes a client for the request. This is usually a browser, editor, Web spider (web crawler), or other end-user tool.

Server/server side (server)

An application that receives a connection by sending back a response service to the request. Any given program can be both a client and a server. The terms we use refer only to the role that the program performs for a particular connection, not the functionality of the usual program. Similarly, by switching behavior based on the nature of each request, any server can act as the source server (Origin server), proxy, Gateway, or pipeline (tunnel).

The server side or client is primarily the role they are in the network.

Source server (Origin server)
A server that resides or creates a given resource.

In other words, the source server is the place where resources are stored, such as servers that hold static resources, servers hosting WEB applications, etc., and for the sake of increasing client responsiveness, static resources are placed separately under a domain name.

Agent (proxy)

An intermediary program that makes requests on behalf of the client as a server side and a client. Requests are processed internally, or translated, and sent to other servers. The agent must implement both client and server-side requirements for this specification. A "Transparent proxy" is a proxy that does not modify requests or responses that exceed proxy authentication and recognition requirements. A "non-transparent proxy" is a proxy that modifies a request or response to provide additional services (value-added services) to the user agent, such as group comment services, media type conversions, protocol simplification, or anonymous filtering. In addition to transparent or opaque behavior to make it clear, the requirements of the HTTP proxy apply to both types of proxies.

Gateways (Gateway)

A server that acts as a mediator for other services. Unlike the proxy, the gateway receives the request as if it were the source server requesting the resource, and the requesting client is unaware that they are communicating with the gateway.

In other words, both the gateway and the proxy receive the user's request. Often end users are unaware that other they are communicating with the gateway.

Cacheable (cacheable)

If a cache is allowed to store a copy of the response information so that it can be used in the answer to the next request, then a response is cacheable. See section 13 of RFC 2616 for rules that determine the HTTP response caching capability. Even if a resource is cacheable, there may be other restrictions, such as whether a cache can use a cached copy for a particular request.

Explicit expiration (explicit expiration time)

This time is, the source server is scheduled, an entity without further validation is no longer returned from the cache.

That is, when the server discovers that the expiration time in the request indicates that the resource in the user's cache has expired, it is no longer possible to obtain resources from the cache.

Absolute time (age)

The absolute time of the response is the start time that was sent from the source server or successfully validated.

Response life cycle (freshness lifetime)

The length of time between the generation of a response and the time it expires.

New (Fresh)

If the age of a response has not exceeded its response life cycle, then the response is new.

Stale (stale)
If a response has exceeded its response life cycle, the response is stale.

Authenticator (Validator)
A protocol element that checks whether a cache entry is an equivalent entity copy, such as an entity label (etags), or the last modified time.

A method used to verify that an entity is out of date.

Request/Response Chain (Request/response chain)

Request Chain------------------------>
UA-------------------v-------------------O
<-----------------------response Chain

HTTP Cache-control Header
The Cache-control header is used to specify the cache instruction, and all request/response chain caching mechanisms must adhere to this directive. This directive specifies behavior intended to prevent the cache from being adversely disturbed by requests or responses. Typically, these directives can override the default cache algorithm. The cache instruction is unidirectional, that is, the presence of a cache instruction in a request does not imply that it also exists in its response.

Note: The http/1.0 cache does not implement Cache-control, only Pragma:no-cache is implemented.

Regardless of the significance of caching instructions (cache directives) to the application, they must be passed through a proxy (browser) or gateway application because the directive can be applied to all recipients on the request/response chain. It is not possible to specify caching instructions for a specific cache. The following are the possible values for Cache-control.

Cache-control = "Cache-control" "": "1#cache-directive

Cache-directive = cache-request-directive
| Cache-response-directive

Cache-request-directive =
"No-cache"
| "No-store"
| "Max-age" "=" delta-seconds
| "Max-stale" ["=" delta-seconds]
| "Min-fresh" "=" delta-seconds
| "No-transform"
| "Only-if-cached"
| Cache-extension

Cache-response-directive =
"Public"
| "Private" ["=" <; " > 1#field-name < >]
| "No-cache" ["=" <; " > 1#field-name < >]
| "No-store"
| "No-transform"
| "Must-revalidate"
| "Proxy-revalidate"
| "Max-age" "=" delta-seconds
| "S-maxage" "=" delta-seconds
| Cache-extension

Cache-extension = token ["=" (token | quoted-string)]

When the 1#field-name field name parameter is not in the directive, the directive applies to the entire request or response. When the 1#field-name parameter appears, it is applied only to the named field, not to the rest of the request or response. The mechanism supports scaling to accommodate future HTTP protocols.

The Cache-control directive, the above possible value, can be divided into the following categories:

The limit of cacheable resources. Can only be done by the source server.
The limit of storage that can be cached. Can be done by the source server or user agent.
Modify the basic expiration mechanism. Can be done by the source service or the user agent.
Controls cache re-authentication and reloading. Can only be done by the user agent.
Controls entity transport.
Extended cache system.

Resources that can be cached
By default, a response is cacheable if the request method, the request header, and the response state need to be indicated to be cacheable. The default caching feature is outlined in section 13.4 of RFC 2616. The following Cache-control response directives allow the source server to overwrite a response to the default caching feature:

Public

Indicates that the response can be cached by any cache, even if it is usually just non-cacheable or cacheable to a non-shared cache. (Refer to RFC 2616, section 14.8 for authorization))

Private

Indicates that all or part of the response information is for a single user and cannot be cached with a shared cache. This allows the source server to indicate that a specific part of the response is used only for one user, whereas a request to another user is an unreliable response. A private (non-shared) cache can cache such a response.

Note: Using private only controls where the response can be cached and does not guarantee the privacy of the information content.

No-cache

If the No-cache directive does not specify Field-name, then a cache cannot use a response to satisfy the next request that is not re-authenticated with the source server. This allows the source server to prevent caching, or even a configured cache, from returning stale responses to the client.

If the No-cache directive specifies one or more field-names, then one cache can use the response to satisfy the next request and to comply with the other limits of the cache. However, the specified Field-name parameter cannot be sent to the next request that is not successfully re-authenticated with the source server in the response. This allows the source server to prevent the reuse of a header in the response, while still caching other parts of the response.

Resources that can be cached for storage
No-store

The purpose of the No-store directive is to prevent inadvertent posting or retention of sensitive information (for example, Backup). The no-store instruction is applied to the entire information and can be sent in a response or request. If it is sent in a request, then the cache cannot store this request or any part of the response to it. If sent in a response, the cache cannot store any part of the response or request it caused. This directive can be applied to shared or non-shared caches. In context, "cannot store" means that the cache cannot intentionally store information on non-volatile reservoirs and, after use, must do its best to remove the information as quickly as possible from the volatile storage.

Even if the directive is used in conjunction with a response, the user may explicitly store the response outside the cache system (for example, the Save as dialog box, or export). The history cache can store the response as part of its normal operation.

The purpose of the directive is to satisfy the requirements specified by some users and service authors, and they are concerned that information is accidentally released by accidentally accessing the cached data structure. While using this directive can improve privacy in some cases, it is important to note that, to some extent, it is unreliable, or a mechanism that is insufficient to ensure privacy. In particular, malicious caches may not recognize or comply with this directive, so that communication networks can easily be tapped.

Modify the basic expiration mechanism
The expiration time of an entity can be specified by the source server via the Expires header (refer to section 14.21 of RFC 2616). Another way is to use the Max-age directive in the response. When the max-age cache directive exists in a cached response, the response is stale if the current absolute time is greater than the value of a new request for that resource at a given time. The max-age directive in the response means that the response is cacheable (that is, "public"), unless there are other, more restrictive cache directives.

If a response contains both the Expires header and the max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows the source server to provide a longer expiration time to the http/1.1 (or later) cache than http/1.0 for a given response. This can be useful if a http/1.0 cache does not calculate the absolute time or expiration time due to an unsynchronized clock.

Many implementations of the http/1.0 cache treat an expiration value that is less than or equal to the response Date value as equivalent to the cache-control response instruction "No-cache". If a http/1.1 cache receives such a response and the response does not contain a Cache-control header, it considers the response as non-cacheable for compatibility with http/1.0.

Note: The source server may want to use a relatively new HTTP cache control feature, such as the "private" directive, in a network that contains an old cache that does not understand the directive. The source server combines this new feature with expiration, which is less than or equal to the date value. This prevents stale cache responses from being cached locally.

S-maxage

If a response contains a s-maxage directive, the maximum absolute time specified by the directive will overwrite the most absolute time specified by the max-age instruction or Expires header for the shared cache (instead of the private cache). The S-maxage directive also implies the semantics of the Proxy-revalidate directive (described in the "controlling cache re-authentication and reloading" section of this document), that is, when the response of the shared cache to the next request becomes stale, the request is not re-validated with the source server. The shared cache cannot use cache entries. The private cache always ignores the s-maxage directive.

Note that most old caches that are incompatible with the above specifications do not implement any Cache-control directives. You want to use the Cache-control directive to restrict the source server, without interfering with the http/1.1-compliant cache, you can overwrite the Expires header with the Max-age directive, in fact, the cache before http/1.1-compliant does not check Max-age instructions.

Other directives allow the user agent to modify the basic expiration mechanism. These directives can be specified in one request:

Max-age

Indicates that the client is willing to receive its absolute time not greater than the specified time, in seconds. The client does not expect to receive a stale response unless the Max-stale directive is also included.

Min-fresh

Indicates that the client is willing to receive a response whose response life cycle is not less than its current absolute time, plus the specified time, in seconds. That is, the client wants a response that is new at least in the specified number of seconds.

Max-stale

Indicates that the client is willing to receive a response that has exceeded its expiration time. If Max-stale is assigned a value, then the client is willing to receive more than its expiration time, not exceeding the specified number of seconds. If the Max-stale value is not assigned, then the client is willing to receive a stale response of any absolute time.

If the cache returns a stale response, either because of a max-stale instruction in a request or because the cache is configured to overwrite the expiration time of a response, the cache must add a warning header of 110 to this stale response.

A cache can be configured to return stale responses without authentication, but only if there is no conflict with any cache validation that requires "must level" (for example, a "must-revalidate" cache control Directive).

If both the new request and the cached entry contain a "max-age" indication, the lesser of the two values is used to determine the new level of the cached entry for the request.

Control cache re-authentication and reloading
Sometimes, the user agent may want or need to persist, a cache with the source server (not just the next cache along the source server path) to re-validate its cache entries, or reload the cache entries from the source server. A peer-to-peer re-authentication may be required if the cache or the source server is too high to estimate the expiration time of the cached response. A point-to-point reload may be required if the cache entry is in no way completely useful for any reason.

You can request point-to-point re-authentication when the client does not have its own locally cached copy, called "Unspecified end-to-end revalidation", or when the client does not have a locally cached copy, called the "specific End-to-end Revalidation ".

The client can specify three actions via the Cache-control request command:

End-to-end Reload

The request contains a "No-cache" cache control directive, or "pragma:no-cache" for compatibility with the http/1.0 client. The No-cache directive in the request cannot contain field-name. When responding to such a request, the server cannot use the cached copy.

Specific End-to-end revalidation

The request contains a "max-age=0" cache control directive, which forces each cache along the source server path, if any, to re-verify its own entries. The initial request contains a cache validation condition with the current authenticator of the client.

Unspecified End-to-end revalidation

The request contains a "max-age=0" cache control directive, which forces each cache along the source server path, if any, to re-verify its own entries. The initial request does not contain a cache validation condition; The first cache with this resource cache entry, if any, contains a cache validation condition with the client's current validator.

Max-age

When a max-age=0 instruction is used to force an intermediate cache to re-validate its own cache entry, and the client has provided its own authenticator in the request, the validator provided may be different from the authenticator currently storing the cache entry. In this case, the cache can also use the authenticator in its own request without affecting semantics.

However, the selection of validators can affect performance. For intermediate caches (proxies), the best approach is to use its own authenticator when making a request. If the server responds to 304 (not Modified), then the cache can return its authenticated copy to the client with a 200 response. However, if the server responds with a new entity and cache validator, the intermediate cache uses a strong comparison function to compare the returned validator with the one provided in the client request. If the client authenticator is equal to the source server, then the intermediate cache (proxy) simply returns the 304 (not Modified) response. Otherwise, a new entity is returned with a (OK) response.

If a request contains a No-cache directive, it should not contain Min-fresh, Max-stale, or max-age.

Only-if-cached

In some cases, such as a very poor network connection, the client may need a cache that returns only those responses that are currently stored, instead of reloading or re-authenticating with the source server. To do this, the client can include the only-if-cached directive in a request. If the server receives this instruction, the cache should either use a cache entry response that is consistent with other requests, or respond with a 504 (Gateway Timeout). However, if a cache group is manipulated within a unified system with a good network connection, such a request may be forwarded within the cache group.

Must-revalidate

Because the cache can be configured to ignore server-specified expiration times, and because a client request can contain a Max-stale directive (with a similar effect), the Protocol also includes a mechanism for the source server to re-validate the cache entry in the next use. When the must-revalidate instruction exists in a response that has been received by the cache, the cache cannot use the entry after the entry for the request that is not next to the original re-authentication of the source server is stale. (That is, if the cached response is old, the cache must complete a point-to-point re-validation every time, based only on the source server Expires header or Max-age value.) ）

The must-revalidate directive is required for the reliable operation of certain protocol functions. In any case, the http/1.1 cache must comply with the Must-revalidate directive; In particular, if the cache cannot reach the source server for any reason, it must generate a 504 (Gateway Timeout) response.

The server should send the must-revalidate instruction when and only if the request for an entity is not successfully re-validated, resulting in an incorrect operation, such as a silent non-executed financial transaction. The recipient cannot automatically perform any action that violates the instruction, and if the re-validation fails, an unauthenticated copy of the entity cannot be supplied automatically.

Although this is not recommended, the user agent under the strict connection restriction operation may violate the directive, and if so, the user must be explicitly warned, providing an unauthenticated response. The warning must be provided to each unauthenticated access, and explicit user acknowledgement information should be required.

Proxy-revalidate

It is the same as the Must-revalidate directive except that the Proxy-revalidate directive cannot be applied to unshared user-agent caches. The proxy-revalidate directive can be used in response to an authorized request to allow the user to cache the store and then return a response without a re-authentication (because it has been authorized once), but the agent is still required to re-authenticate the user (to ensure that each user is authorized).

Note that this authorized response also requires public cache control directives so that they are fully cached.

No-transform directive
No-transform

Implementers of intermediate caches (proxies) have found it useful to convert the media type of an entity body. For example, a non-transparent proxy converts the image to a format that saves cache space or reduces traffic in a slow link.

However, when these transformations are applied to a solid body for some application, serious operational problems occur. For example, medical imaging, scientific data analysis, and peer-to-peer licensing applications all depend on the entity being received, and each bit is consistent with the original entity.

Therefore, if a message contains a no-transform instruction, then the intermediate cache or proxy cannot change the header (see RFC 2616, section 13.5, 2). This means that the cache or proxy cannot change any aspect of the entity body specified by the header, including the value of the entity itself.

Cache control Extensions
The Cache-control header can be extended by using one or more cache-extension tags, and an optional value is assigned to each tag. You can add information extensions (no need to change the caching behavior) without changing the semantics of these directives. The design behavior is extended by using the existing basic cache directives as modifiers. The application that does not understand the new directive will default to the behavior of the standard directives, and those that understand the new instructions will be able to modify the requirements with the standard directives by providing both new and standard directives. In this way, you can extend the Cache-control directive without changing the basic protocol.

The extension mechanism depends on complying with all the cache control directives defined in its local HTTP version, as well as a degree of extension, and ignoring all instructions that it does not understand.

For example, suppose a new response instruction called "community", which acts as a modifier for a private directive. The implication of this new directive is that, in addition to any non-shared cache, the response can be cached only by any cache that is shared by the specified community member. The source server wants to allow UCI community to use the private response in their cache as follows

Cache-control:private, community= "UCI"
A cache that sees this header will perform the correct behavior, even if the cache does not understand the Community cache extension, because it will also see and understand the private directive, so go on to perform the default security behavior.

Unrecognized cache directives must be ignored. It assumes that any cache instruction that may not be recognized by the http/1.1 cache will be combined with a standard instruction (or response to the default caching feature) so that the caching behavior will be kept to a minimum, even if the cache does not understand the extension.

Resources
Wiki:hypertext Transfer Protocol Http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

RFC 2616:hypertext Transfer Protocol--http/1.1 http://tools.ietf.org/html/rfc2616

W3.org:a detailed technical History of HTTP http://www.w3.org/Protocols/History.html

W3.org:Design issues by Berners-lee if he was designing the Protocol http://www.w3.org/Protocols/DesignIssues.html

Wiki:list of HTTP header fields Http://en.wikipedia.org/wiki/List_of_HTTP_headers

Httpwatch.com:HTTP Headers http://www.httpwatch.com/httpgallery/headers/

Microsoft.com:HTTP Response headers:http://msdn.microsoft.com/en-us/library/ms537417 (v=vs.85). aspx

RFC 4229:http Header Field registrations http://tools.ietf.org/html/rfc4229

Internet Explorer and Custom HTTP headers-ericlaw ' s ieinternals-site home-msdn Blogs http://blogs.msdn.com/b/ieinter Nals/archive/2009/06/30/internet-explorer-custom-http-headers.aspx

HTTP Request Header Viewer http://www.myhttp.info/

HTTP Response Header viewer-retrieves the HTTP Response headers of any domain http://viewdns.info/httpheaders/

HTTP Header with Privacyinfo-display your HTTP request and response headers Http://www.privacyinfo.org/http-headers

MSDN Metal http-equiv http://msdn.microsoft.com/en-us/library/ms533876 (v=vs.85). aspx

HTTP protocol Cache-control Header--Performance AH