There are many kinds of caches: Server cache, third-party cache, browser cache, and so on. The browser cache is the least expensive, because the browser cache relies on the client and consumes little server-side resources.
Making the browser cache requires sending a specified Http header to the browser, telling the browser how long to cache it, or not caching it firmly.
1.Expires (Expiry time) HTTP header information The Expires (Expiration Time) attribute is the basic means of the HTTP control cache, which tells the cache: how long the relevant copy is fresh. After this time, the cache sends a request to the source server to check if the document has been modified. Almost all cache servers support the expires (Expiration time) attribute;
Most Web servers support you in several ways to set the Expires property; general: You can design an absolute time interval based on the time at which the client last viewed the copy (last access time) or the last time the document was modified based on the server;
Expires Header information: Caching is especially useful for setting up static picture files (such as navigation bars and picture buttons), because they are rarely modified, and you can give them a particularly long expiration time, which makes your site very fast for users, and they are also useful for controlling web pages that change regularly. For example: You update the news page at 6 o ' Day in the morning, and you can set the expiration time of the copy so that the cache server knows when to fetch an updated version without having the user press the browser's refresh button.
The Expiration header Information property value can only be a datetime in HTTP format, the other will be resolved to the current time "before", the copy will expire, remember: the date time of HTTP must be GMT, not local time. Example:
Expires:fri, OCT 1998 14:19:41
So use the expiration Time property to make sure that your Web server time is set correctly, one way is through Network Time Synchronization protocol (Protocol NTP), and your system administrator where you can learn more details.
Although the expiration time attribute is useful, it has some limitations, first: the date is involved, so that the time of the Web server and the cache server time must be synchronous, if there are some out of sync, either the content should be cached prematurely expired, or the expired results are not updated in time.
There is also an expiration time setting the problem should not be ignored: if you set the expiration time is a fixed time, if you return content when there is no update the next time, then all access requests will be sent to the source Web server, but increased load and response time;
2.cache-control (Cache control) HTTP header information
HTTP 1.1 describes another set of header information properties: Cache-control response header information that allows publishers of the site to more fully control their content and to locate limits on expiration time.
Useful Cache-control response header information includes:
max-age=[seconds-the maximum time to execute the cache is considered to be up to date. Similar to the expiration time, this parameter is based on the relative time interval of the request time, not the absolute expiration time, [seconds] is a number in seconds: the number of seconds from the start of the request to the expiration time.
s-maxage=[sec--similar to the Max-age property, except that he applies to a share (such as a proxy server) cache
public-Tag authentication content can also be cached, generally speaking: HTTP authentication to access the content, the output is automatically not cacheable;
No-cache-forces each request to be sent directly to the source server without verifying the local cached version. This is useful for verifying the authentication application (which can be used in conjunction with public), or for applications that use the latest data (at the expense of all the benefits of using the cache);
no-store-to persist any replicas in any case
Must-revalidate-tells the cache to follow all of the freshness you give to the replica, HTTP allows caching to return expired data in certain specific cases, specifies this property, you cache, and you want to strictly follow your rules.
proxy-revalidate-is similar to must-revalidate except that he only works with the caching proxy server
Example:
cache-control:max-age=3600, Must-revalidate
Repsone plus Expires/cache-control header for static resources (HTML files, picture files, etc.) is a very effective trick. If the HTTP response has a header such as expires, the browser will cache this resource, ideally (note, just the ideal), before the expire date, the HTTP request will not be sent to the server for this resource, However, the value of expires can only be a fixed date, such as "Thu 07:00:00 GMT", can not be a similar "from now on 10" such a random floating value, if you want such an effect, You can use a header such as Cache-control, if the HTTP response has such a header: "Cache-control:max-age = 100", indicating that the maximum lifetime of this resource in the Cache is 100 seconds. In general, this static file should never expire, if you really want to add a deadline for this Cache, then I hope is-10,000 years, "cache-control:max-age = 315360000000"
In fact, you should set a expires will never expire time, such as you now have a file called logo.gif, need to use a new logo when you do not overwrite the original file, and the new logo into Logo_v2.gif, so that the relevant web page reference to the new Logo_ V2.gif, this allows the new and old web pages to work at the same time, it is not necessary to save storage space to overwrite the original files.
For Apache servers, use Mod_expires, add in httpd.conf or. htaccess
<filesmatch "\ \. (ico|gif|jpg|html) $ ">expiresdefault" Access plus years "</FileMatch>
3.last-modified/if-modified-since
Some of the data is changing all the time. CNN.com's homepage is often updated in a few minutes. On the other hand,Googlecom's homepage is updated only a few weeks (when they upload a special holiday logo or advertise for a new service). The WEB service is constant: the server usually knows the last modification time of the data you requested, and HTTP provides a way for the server to send the most recently modified data together with the data you requested.
If you request the same data the second time (or the third, or fourth time), you can tell the server the last modified date you got: Send a if-modified-since header message in your request that contains the last date that was obtained from the server along with the data. If the data has not changed since then, the server will return a special HTTP status code of 304, which means "this data has not changed since the last request". What progress does this make? When the server sends a status code of 304, the data is no longer resent. You only get this status code. So when the data is not updated, you don't need to download the same data again and again; The server assumes you have local cache data.
All modern browsers support recently modified (last-modified) data checks. If you've ever visited a page, re-visited the same page after a day and found it unchanged, and wondered if the page was loaded so fast on the second visit-that's why. Your browser will cache the contents of the page locally when you first access it, and when you visit it for the second time, the browser automatically sends the last modified date from the server when you first visit. The server simply returns 304:not Modified (without modification), so the browser knows to load the page from the local cache. At this point, Web services are also so intelligent.
4. Etag/if-none-match
The ETag is another way to implement the same functionality as the most recently modified data check: Do not re-download data without changes. It works by sending a hash of some kind of data (given in the ETAG header information) while the server sends the data you requested. The determination of the hash depends entirely on the server. When you request the same data for the second time, you need to include the ETAG hash in the If-none-match: Header message, and if the data is not changed, the server returns a 304 status code. As with the last modified data check, the server simply sends a 304 status code, and the second time will not send the same data for you. On the second request, by including the ETag hash, you tell the server that there is no need to resend the same data if the hash still matches, because you have the last accessed data.
These HTTP headers can be sent to the client as meta tags, but it is important to note that the settings in the HTTP header are higher priority, for example:
<meta. http-equiv= "Expires" content= "Fri, OCT 1998 14:19:41″>
<meta. http-equiv= "Cache-control" content= "No-cache" >
Summarize
The Expires/cache-control header is the control of whether the browser caches data directly from the browser or re-sends requests to the server to fetch data. Just Cache-control can control more than expires, and Cache-control will rewrite the rules of expires.
Last-modified/if-modified-since and Etag/if-none-match is the browser to send a request to the server to determine whether the file has been modified, if not modified to send only a 304 back to the browser, Tells the browser to fetch data directly from its own local cache, and if modified, sends the entire data back to the browser.
HTTP Header Description: Expires,cache-control,last-modified,etag