| only for RuBoard - do not distribute or recompile | |
To reduce bandwidth usage and latency, clients are encouraged to cache the data retrieved from a web server.
On sites with proxy servers, the proxy can also work as a cache. This allows a user of the proxy server to use documents that might have been previously retrieved and cached by other users of the proxy.
A complication with caching, however, is that the client or proxy needs to know when the document has changed on the server. HTTP provides a mechanism for cache management through a set of headers. There are two general methods for determining if a server resource has changed. One method checks for the most recent modification time of the document. Another method checks for modifications in the entity tag associated with the document.
The server can also use the Cache-Control and Pragma headers to indicate caching properties to the client. Some documents aren't appropriate for caching, either for security reasons or because they are dynamic documents (e.g., created on the fly by a CGI script). Under HTTP 1.0, the Pragma header with a no-cache value indicates the document should not be cached. Under HTTP 1.1, the Cache-Control header supplants Pragma, with several caching directives in addition to no-cache.
To accommodate client-side caching of documents, the client can use the If-Modified-Since header with the GET method. When using this option, the client requests the server to send the requested information associated with the URL only if it has been modified since a client-specified time.
If the document was modified, the server will give a status code of 200 and returns the document in the entity-body of its reply. If the document was not modified, the server will give a response code of 304 (Not Modified).
An example If-Modified-Since header might read:
If-Modified-Since: Fri, 02-Jun-95 02:42:43 GMT
If the server returns a code of 304, the document has not been modified since the specified time. The client can use the cached version of the document. If the document is newer, the server will send it along with a 200 (OK) code. Servers may also include a Last-Modified header with the document, to let the user know when the last change was made to the document.
Another related client header is If-Unmodified-Since, which says to only send the document if it hasn't been changed since the specified date. This is useful for ensuring that the data is exactly the way you wanted it to be. For example, if you GET a document from a server, make changes in a publishing tool, and PUT it back to the server, you can use the If-Unmodified-Since header to verify that the changes you made are accepted by the server only if the previous one you were looking at is still there.
If the server contains an Expires header, this indicates the document will not change before the time specified in the header. Although there are no guarantees, it means that the client does not have to ask the server about the last modified date of the document again until after the expiration date.
In HTTP 1.1, a new method of cache management involves entity tags. The problem solved by entity tags is that there may be several copies of the same document on the server. The client has no way of knowing that it's the same document—so even if it the client already has a copy of the document, the client will request the document again.
Entity tags are unique identifiers that can be associated with all copies of the document. If the document changes, the entity tag changes—so it is more efficient to check for the entity tag, not for the URL and Last-Modified date.
If the server uses entity tags, it sends the document with the ETag header. When the client wants to verify if a document matches a particular entity tag, it uses the If-Match or If-None-Match header.
| only for RuBoard - do not distribute or recompile | |