3.7 Cache Busting and Server Busting
| only for RuBoard - do not distribute or recompile |
3.7 Cache Busting and Server Busting
Cache busting is a technique that content providers use to prevent their pages from being served as hits from caches. Often this means making every response uncachable. This issue is difficult to assess for a number of reasons. First and foremost, owners and publishers have legal rights to control the distribution of their information. Whether or not we agree with their decision to defeat caching, the choice is theirs to make. Usually, their reasons are unknown to us, but the reasons might include the copyright issues discussed previously or the desire to increase the number and accuracy of their hit counts. Second, some content providers, by the very nature of their business, might serve only uncachable content. We should not be surprised to find that sites that exist only to count advertisement impressions do not allow their responses to be cached. Issues relating to advertising are explored further in the next section.
How would someone be able to claim that an origin server is cache busting? Cache users and administrators sometimes expect certain types of objects to be cachable by default. When users visit a page for the first time and then access it again a short while later, they expect the page to load very quickly because it should be in the cache. When the page loads slowly, they wonder why. If a user is curious and savvy enough, she might find a way to examine the reply headers firsthand. With access to the cache log files, administrators can easily analyze them and generate reports including hit ratios for individual origin servers. Those servers that give a lower than average amount of hits, or no hits at all, might be suspects for cache busting.
On the other side of this issue are the Internet service providers who pay high, or perhaps metered , tariffs for their bandwidth. They turn to caching as a way to save money. In a sense, cache-busting web servers represent additional costs for the ISP. When Internet charges are usage-based , rather than flat-rate, people often feel they have purchased information when they download it, and they should not have to pay to download it again.
Some caching software allows administrators to override the server's instructions for cache behavior. A cache configured in this manner blatantly violates the HTTP standard. Server busting might be an appropriate term for such behavior. This is a dangerous path to start down, as it essentially leads to an "arms race" between caches and origin servers. If caches ignore an origin server's requirements, content providers will find new ways to defeat caching. Instead of working against each other, we should be having a dialogue and finding ways to cooperate.
The development of a hit-metering mechanism for HTTP [Mogul and Leach, 1997] is a step in the right direction. Hit metering works in two ways: by reporting unvalidated cache hits back to origin servers and by limiting the number of hits before requiring validation. These mechanisms offer content providers some control over the distribution of their pages, as well as better statistics regarding cache hits. Caches are not required to support both reporting and limiting. For example, a cache can say that it will limit cache hits but not provide hit count statistics. Unfortunately, there has been little demand for hit metering from content providers. Without such demand, we may never see hit metering implemented or widely deployed.
| only for RuBoard - do not distribute or recompile |
