Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)                      9  TCP/IP Hypertext Transfer Protocol (HTTP)                           9  HTTP Features, Capabilities and Issues

HTTP Features, Capabilities and Issues 1 2 3 HTTP Proxy Servers and Proxying

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 CNN’s Web site, it is probable that the CNN logo won’t change very often, but it’s 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 cache—a process called aging—the 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 A’s 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.

HTTP Features, Capabilities and Issues 1 2 3 HTTP Proxy Servers and Proxying