Cache freshness Judgment

This time the main thing to say is how the cache is the freshness of judgment. The last book says that every resource in the cache has its own shelf life, which we call freshness. When a resource is in this shelf life, the cache thinks it is fresh and can be sent to the client without having to verify it again. So what is the definition of this shelf life? And how to verify when the shelf life is over?

Resource Expiration

With the Cache-control header and expires header, the original server can define its shelf life for the resource. Within the expiration date, the cache considers the resource to be fresh and can be passed back directly to the client, which needs to be re-verified if it expires.

Cache-control header and Expires header are actually defined as resource expiration time, Cache-control use relative time, and expires use absolute time, absolute time depends on computer clock, So it is recommended to use Cache-control header.

Baidu home This transaction is using the Expires header, and the Cache-control header form is this:

cache-control:max-age=484200

This unit is seconds. Expires first better understand, he just said that the date this resource expires. The Cache-control header indicates how many seconds after the resource has been generated from the server before the resource expires.

Server re-authentication

What if the resource expires? Re-verify. How do I verify it again? Why do we need to validate again? When a resource in the cache expires, it does not mean that the resource is really out of date, and that the resource server may not have changed during this time period. So in order to verify that the resources that have expired are really different, you need to re-verify. If you re-verify that the display resource has changed, the cache gets a new copy of the resource. If you re-verify that the display resource has not changed, the cache will only get a new header, including a new expiration date and update the information in the cache.

The HTTP protocol requires that the cache correctly return one of the following:

• Fresh enough copies of resources
• Re-authenticate with the server and confirm that it still has a fresh copy of the resource
• Returns an error message if a server that requires re-authentication fails
• A copy of the resource with a warning message stating that the content may be incorrect

How do I perform cache validation?

http can be efficiently re-validated using conditional methods. The protocol allows the cache to send a conditional GETto the server, and returns only the relevant header if the resource has changed. If the resource has changed, the corresponding resource object is returned directly in the corresponding message. Five conditional request headers are defined in HTTP, with if-modified-since and if-none-match two headers.

if-modified-since: If the resource has been modified since the specified date, then the new resource is returned and can be used with the last-modified header

if-none-match: The server can define a specific label for each resource, and if the label for the re-authenticated copy resource is different from the label on the current server, the new resource is returned.

The most common is if-modified-since, aif-modified-since request, commonly referred to as an IMS request, is literally known to indicate that the server will not return a new resource until the resource has been transformed since a certain date. If the resource has been modified since the specified date, the server will return a response message that includes the new header new expiration date and the new resource. If the resource has not been modified, then the server will not send the resource, only the new header and expiration time will be sent.

The if-modified-since header can be used with the last-modified header, and the server appends the last modification time to the message being echoed. When validating, you can use If-modified-since: (last modified time) this way to validate, which means that the resource has not changed since the last modification. If the resource does not change, the server will echo a 304 not modified response.

Some servers do not compare the information in if-modified-since as a time, but rather a string match. This method verifies that the resource is not a specific time resource. This is a good way to identify whether the cache is out of date, but if the client wants to do some other real time-based work with that time, the problem will arise.

In some cases it is not enough to use only date validation

For example, some documents may be rewritten periodically, but they do not actually change. Some documents have changed, but these changes are not important, they do not need to be updated by the cache, and so on. In this case, it is necessary to use the ETag and if-none-match to verify the problem. The entity tag can be likened to the version number of the resource, when the validation, the ETag in the cache and the server resource ETag comparison, to see if the requirements are met, if not match, then loopback new resources.

The If-none-match header can contain several etag to tell the server that the entities already exist in the cache. For example:

If-none-match: "v1.0", "v1.1", "v1.2"

Strength Validator

Sometimes a weak validator can be used when the server wants to make some non-substantive or unimportant changes to the document without having to invalidate all the caches. For example, the version number under v2.6, such as v2.63, are considered to be fresh. So how do you use weak validators? Example:

etag:w/"v1.0"

if-none-match:w/"v1.0"

(just add w/.) ）

The original server must not reuse a specific strong entity tag value for two different entities, or reuse a specific weak entity tag value for two semantically different entities, because the replicas remain in the cache for an irregular period of time and are prone to collisions.

When do I use the entity label and the last modified date?

If the server sends back an ETAG, the client must use the Entity tag validator, and if the server sends a last-modified value, the client can use If-modified-since authentication. If all is provided, then it can be used.

Unless the http/1.1 original server cannot generate an entity tag validator, it should be sent out.
Original address:
Http://www.cnblogs.com/littlewish/archive/2013/02/28/2936004.html

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Cache freshness Judgment