| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
HTTP Caching Features and Issues (Page 3 of 3) Important Caching Issues While the performance advantages of caching make it a "no-brainer", there is no denying that caching has one significant drawback: it complicates the operation of HTTP in a number of ways. Below is a description of some of the more important issues that HTTP/1.1 clients, servers and intermediaries need to deal with. As long as it is, this list is not exhaustive, which gives you an idea of what is involved with caching in HTTP (as well as why the standard needed 26 pages to cover the subject!) When a user retrieves a document directly from its original source on the server, he or she always is assured of getting the current version of that resource. When caching is used, that is no longer the case. While many resources change infrequently, almost all will change at some point in time. To take the example above of CNNs Web site, it is probable that the CNN logo wont change very often, but its possible that the site may be redesigned periodically and the logo modified in some way, such as its size or color. For this reason, a device cannot keep items in an HTTP cache indefinitely. The longer an item is held in a cachea process called agingthe more likely it is that the resource on the server has changed and the cache has become stale. To make matters even more complex, some resources become stale more quickly than others. As a result, much of the caching-related functionality of HTTP is related to dealing with this matter of cache aging. One of the ways that HTTP deals with the cache aging issue is through headers and logic that allow caches, clients and servers to specify how long items should be cached before they expire and must be refreshed. A process of validation is also defined that allows a cache to check with a server at appropriate times to see if an item it has stored has been modified. In most cases, the fact that an item has been retrieved from a cache rather than its source is transparent to the user (though he or she may notice that the resource loads faster than expected!) In certain cases, however, the user may need to be informed that a resource came from a cache and not its original source. This is especially true when a cached item may be stale, in which case the client should warn the user that the information might be out of date. Caching in HTTP is complicated by the fact that it can occur in multiple places, and some HTTP headers are treated differently than others. HTTP headers are divided into two general categories: end-to-end headers that are intended to accompany a resource all the way to its ultimate recipient, and hop-by-hop headers that are used only for a particular communication between two devices (be they client, server, or intermediary device). End-to-end headers must be stored with a cached resource, where hop-by-hop headers only have meaning for a particular transfer and are not cached. Some HTTP methods will automatically cause cache entries to become invalidated, because they inherently cause a change to the underlying resource. For example, if a user performs a PUT on a resource that was previously retrieved using GET, any cached copies of that resource should be automatically invalidated to prevent the old version from being supplied from the cache. In the case of shared caches (such as might exist in a proxy) there are potential privacy issues to be concerned with. While in most cases having user As cached resource be made available to user B is advantageous, we must be careful not to cache any items that might be specific to user A, which user B should not see.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |