Rails week 1 (d): Browser Cache

Jun 16 posted in Ruby (RSS), comments.

Note that we have talked about was the browser cache. About Rails server-side cache, after the special opening title to talk about it anymore.

HTTP protocol to support Cache

All in all, cache mechanism in order to reduce the number of request to send (measured by the model), also is to reduce the chance of sending the entire response in order to reduce the use of network bandwidth (validation model).

HTTP protocol in which, there are three ways to control cache.

1. Cache-Control

Cache-Control has a series of instructions to be told what to take to deal with cache, such as no-cache, no-store, max-age, must-revalidate, etc.. Cache-Control is the only explicit instructions. Other models, such as outdated model and verify the model, are implicitly told how to deal with cache.

Cache-Control has a lot of different directions. If there is apparent conflict, generally the most stringent way to explain.

2. Expired Model (Expiration Model)

Use of outdated models, at set time limit expired, it will not really to the server initiated the request, but directly back cache.

This approach tends to be used in a number of a lot of static pages, or basically at a certain period of time will not change on the page. Such as google's home page at some places of worship in general will not change.

Client Services through the Expires header or Cache-Control of the max-age command to set the expiration time (the latter being a higher priority class, if specified at the same time, the latter covering the former).

3. Verification Model (Validation Model)

When the cache has an old entry, want to use it as a response the client request, it is necessary to check whether the cache can use the entry (in this application is not based on an outdated model of the cache, but the default cache mode). This is the authentication model.

Server-side validation will be conducted, if the authentication does match, then return 304 (Not Modified) status code, but it will not return entity-body. Otherwise, the return of the response (including entity-body).

Time model can be used to verify, checksum, etc. for verification. Associated with the command to verify the model there is: last-modifed, if-modified-since, ETag, if-none-match and so on.

For these three models in times of conflict the priority of the relationship, I did not go well analysis. However, certain types of behavior can be seen through, Expire priority in Validation, and some Cache-Control or Expires instructions Validation can also kill.

Modern web servers and browser support for the Cache

Use firebug to track a bit and found that the existing web server (even if Mongrel) and the browser cache did a very good job. For such as css, javascript, image, etc., are automatically taken to verify the model cache.

For instance for a first visit to a static document, response heder contains a value:

Last-Modified	Wed, 25 Mar 2009 15:07:30 GMT
Etag"49ca48b2-1faca-140dbf"

The request of the first follow-up there will be some value as follows:

If-Modified-Since	Wed, 25 Mar 2009 15:07:30 GMT
If-None-Match	"49ca48b2-1faca-140dbf"
Cache-Control	max-age=0

The appropriate response status code is 304 (Not Modified), and response header becomes:

Connection	close
Date	Mon, 06 Apr 2009 09:32:46 GMT
Etag	"49ca48b2-1faca-140dbf"

Even for some dynamic HTML, will also verify the model using the cache management.

The first visit back a response header which contains ETag:

Etag	"eb448ad46a55ed596680bc713de1105a"

Second request contains a header inside the If-None-Match:

If-None-Match	"eb448ad46a55ed596680bc713de1105a"

Are the response and the 304 (Not Modified).

However, inside the third request, they will not contain If-None-Match. Such a cycle. It is estimated that the new features of FF3 are reasonable to reduce all of the page re-load opportunities.

Rails to encourage us to take what kind of cache ways

Rails will be the default for javascript, css, image files and other resources on the path behind the attached document was last modified. So why did they want to do this? Obviously, Rails are you at encouraging the use of expired model files to cache these resources.

Such as in Apache, the use of such static allocation of resources to make these documents cache.

     ExpiresActive On
     <FilesMatch "\.(ico|gif|jpe?g|png|js|css)$">
          ExpiresDefault "access plus 1 year"
     </FilesMatch>

Added after the configuration. Js and other documents on request which will be the first of many reponse the following two header.

Cache-Control	max-age=31536000
Expires	Tue, 06 Apr 2010 09:28:49 GMT

At the request of then, as long as a document not yet expired, the client do not need to request access to be launched again Cache resources. At the same time, once the document has any change, the browser can access the new document. Because the path has been modified in accordance with the last change.

It is noteworthy that only because the browser to limit at most the same address simultaneously launched two requests, so we will use the resources of multiple servers (see AssetTagHelper Doc Learn how to use the resources of multiple servers), then each server to ensure that time synchronization is essential. Resources or because the server will randomly select, url after the time stamp attached to often change, resulting in failure cache.

Two simple rules Cache

For web applications now, I agree with the principle of the following two cache.

Don't cache HTML

1. Use Cache-Control: no-cache for dynamic HTML pages

2. Use the Last-Modified header with the current file time for static HTML

Cache everything else forever

1. For all other file types set an Expires header to the maximum future date your web server will allow

2. Modify URLs by appending a query string in your HTML to any page element you wish to 'expire' immediately.

The End!