Frequently Asked Questions for CacheRight



I am a Web developer/designer, why should I worry about cache control?

There are three major reasons for anyone to support caching:

  1. It saves bandwidth
  2. It reduces server loads
  3. It makes Web sites load faster

This means improved Web site performance for end users and reduced total cost of ownership for site owners.

If the idea of satisfied end users and site owners isn't a sufficient incentive for you, here is another reason to care about having good, effective cache control policies: since caches (both browser and proxy) are ubiquitous on the Web, every site you deploy will be significantly affected by caching, whether you like it or not. If you do nothing to control how your Web sites are cached, then someone else's software will make those decisions for you. This is why, if you are a professional Web developer, correct cache control policies should be as much a part of the Web sites you deliver and maintain as the HTML, images, stylesheets and JavaScript. Professionals simply don't leave such important details to chance -- and CacheRight is the first tool that makes it practical for you not to.

back to top


I always use META tags to control caching. Why isn't this good enough?

There are two reasons to be wary of relying on META tags for cache control of HTML files. First, since META tags are embedded in the HTML page itself, they are generally ignored by shared (proxy) caches, which read only the HTTP headers. Second, even browser caches are not guaranteed to honor the cache control information contained in META tags. Whether or not they do (and what tag syntax and/or placement is required to satisfy them) is entirely dependent on browser vendor and version. Lastly, META tags are obviously of no use at all when it comes to controlling the caching of images and other Web objects in which these tags cannot be embedded -- objects that constitute the bulk of Web page payloads.

back to top


Can good cache control policies really improve my site's performance?

Absolutely. Caching indisputably saves bandwidth and server resources because it reduces network traffic. It does this by reducing the number of round-trips between Web clients and Web servers. This is why shared (proxy) caches exist on the Internet and corporate intranets: infrastructure providers and corporate IT departments make extensive investments in caching technology because the savings are too great to pass up.

Improved site performance is simply the other side of this coin. Caching indisputably improves site performance because it reduces network latency. It does this by allowing Web clients to retrieve content from a cache that is located much closer to them than the Web server from which the content originally came. Given normal Web browsing conditions, a cached object will always load faster than an uncached one. Our testing shows that an uncached image can take 0.5 seconds to be verified by an origin server - multiply this lag by the number of images on a page, and your users could be waiting a very long time indeed without cache control.

back to top


I don't cache anything because I'm afraid of end users getting out-of-date content. How can I prevent this using CacheRight?

The fear of over-aggressive caching is an understandable one, given how difficult it usually is to control how the different parts of a Web site will be cached. Faced with one-size-fits-all cache control that risks saddling users with old or wrong content, it's hardly surprising that Web developers throw up their hands. This explains why the vast majority of objects on the Web lack basic cache control.

However, ignoring the role of caches (and thus surrendering the benefits of caching) is no way to solve the problem of over-aggressive or unwanted caching. Instead, objects that shouldn't be cached need to have cache-control headers and directives specifying immediate expiration. This doesn't guarantee that some piece of software, somewhere, won't try to cache them -- but objects that lack the appropriate headers and directives don't even stand a chance of being cached correctly.

A better solution than giving up on cache control is to use a tool that makes it easy to implement and manage correctly. This is where CacheRight comes in. Using CacheRight rules, you can set unique expiration times for files in different locations or for files having different MIME types. Expiration times can be absolute dates or intervals relative to a file's last modification, or to the user's last access. CacheRight rules are also written in a simple declarative syntax and kept in a single text file that is as easy to update as an ordinary HTML page. Creating correct cache control policies is still up to you, but CacheRight makes implementing and maintaining those policies as painless as possible.

back to top


I really need to clear a cached file, how do I do this?

By definition, once a local cache has what it considers a "fresh" copy of a file, it stops asking the origin server for new copies or to tell it whether the one it has, has been changed. At this point, there isn't much you can do to flush the remote cache, short of changing the name of the file -- and all the associated links that point to it. Unless you happen to be running a sophisticated Content Management System (CMS), this is going to be quite a chore. However, following a few common sense design tips can make such situations easier to deal with when they do occur.

Keep in mind that, while limited caching of markup files (HTML/XHTML/XML) can be useful, the real benefit of caching comes from the caching of images. Since your markup serves as a skeleton for your Web page, if it is too-aggressively cached, you may find that the images and other objects linked to the page can not be modified when they need to be. You may have to rename the page (and risk breaking navigation, bookmarks and so on), when the only thing that has changed in it is a single image. However, if your markup is set to expire immediately (or after a relatively-short interval), and more aggressive caching is confined to the associated images, you can then easily change the names of any of these images -- forcing new versions to be used instead of cached ones. Such a cache control policy makes emergencies much easier to contend with, since it tends to limit the damage (and the recoding required to repair it).

back to top


Can't IIS already set cache control headers for me?

Yes, to a certain degree, but even what it does provide may not do you much good unless you happen to be the IIS administrator. Provided that you have access to the IIS Web server's Microsoft Management Console (MMC) Snap-in interface, you can use its "HTTP Headers" property sheets to set expiration times for an entire site, a particular branch of the site, a single directory, or even a single file. Unfortunately, many Web developers lack this kind of access to a production Web server's administrative interface. Even when granted such access, using MMC property sheets to manage cache control policies is not especially convenient -- in order to edit expiration times in several different places, one must do a lot of drilling-down and clicking-through to get at the appropriate property sheets. Most importantly, there is no single view of all the cache control policies on the site.

While you could, with a lot of patience, use the MMC to mimic the effect of certain CacheRight rules, such as ExpiresByPath, some rules cannot easily be emulated using the MMC. For example, there is no native equivalent in IIS to the ExpiresByType rule in CacheRight, which lets you set a single expiration time for all files of the same MIME type, no matter where they happen to be located.

Even if IIS offered the same flexibility as CacheRight in the setting of expiration times, it would still lack CacheRight's support for all of the standard cache control headers and directives. CacheRight employs the full range of HTTP 1.0 and 1.1 mechanisms required to implement your expiration rules -- including useful but frequently-ignored directives like public, private, no-transform, no-cache, no-store, must-revalidate, proxy-revalidate, and so on. You could of course read the specification and implement these headers and directives manually using the MMC property sheets, but doing so would be far beyond the knowledge (or at least the patience) of even many advanced IIS administrators.

back to top


As a developer, CacheRight is supposed to make my life easier, yet the documentation tells me that I have to learn to write special "rules." That doesn't sound very easy to me.

The rules that CacheRight uses to determine what cache-control headers to send for a given request are very easy to write -- no more difficult, probably, than trying to remember the syntax of the various META tags that are supposed to (but often don't) control the caching of your HTML pages. Ten or fifteen minutes spent playing around with a few example CacheRight rules is all the "training" most Web developers will ever need, and CacheRight comes with an extensive sample rules file to help get you started. And unlike META tags, CacheRight rules all live in one place -- a single text file (called rules.cr) that is kept in a Web site's home or root directory. In fact, if you structure your site well (for example, by keeping all the images you want to cache in a special directory), you may find that just two or three rules can replace a site full of META tags.

back to top


Once I start using CacheRight, how can I be sure it is sending the right cache-control headers?

What you will need is a tool that can request various Web pages and objects and show you the HTTP headers that the Web server sends back with each requested resource. Such header-scanning functionality is part of the CacheCheck tool, available on our Tools page. CacheCheck is a server-based tool that makes HTTP requests on your behalf and shows you either a summary of the cachability of the requested resource or a detailed report including all the cache-related headers sent by the server. Use the detailed report mode to verify that CacheRight is doing its job. Details about what to look for in the headers are available in the CacheRight help file. If you would rather use a header-scanning tool that can be run from your own desktop (or if you must use such a tool because the Web site whose cache-related headers you want to examine is on a server located behind a firewall), then free ieHTTPHeaders is a good choice.

back to top


I have heard of other products that provide caching solutions for ASP, ColdFusion, PHP and IIS. How does CacheRight differ?

CacheRight is not specific to a particular language, nor does it save generated pages like a reverse proxy cache. It is purely meant to set cache control headers properly and to provide a mechanism for developers to have some control over the caching and performance characteristics of their own sites, rather than hoping that the site administrator has taken care of it. CacheRight also aims to do this at an attractive price point -- far below the thousand to multi-thousand dollar price tags associated with many cache-related products on the market. Put simply, our goal is to provide developers with maximum functionality for a minimum price.

back to top


Apart from reducing bandwidth consumption and latency, what kind of impact is the CacheRight software going to have on my Web site's performance?

As an ISAPI filter, CacheRight's impact on Web server performance is negligible. Our extensive load and stress testing have shown it to have only a slight impact on server memory usage and maximum number of connections under peak loads.

back to top


Do you have an Apache version of your product?

No. All Port80 Software is designed to work with IIS. This represents a conscious effort on our part to bring competitive server technology to the IIS platform. Functionality similar to CacheRight's is provided by the Apache module mod_expires.

back to top


Will my files still be cached with CacheRight if I'm using an SSL connection?

Browsers do deal differently with SSL requests but expiration-based caching can still be effective. In the case of IE 7's default caching behavior, for example, the following limitations apply:

With SSL requests, Expires or Cache-Control headers will be ignored for the containing page itself. For instance, given a non-SSL connection, if a page were static HTML page and had cache control headers giving it an expiration lifetime of 2 weeks, and it were requested on a return visit, the browser would use the file in its cache. Whereas, if the connection were SSL, the page would be rerequested from the server each time. That is the bad news.

Fortunately however, this does not apply to the dependent objects (images, js, css) used by such a page. If those objects are being served with proper cache control headers (as created by CacheRight) they will be served from the cache on a return visit, even though the connection is over SSL.

The one limitation here is that the different protocols do create different caching namespaces. Thus, even if the SSL and non-SSL parts of the site share dependent objects (such as images, css and js) the objects cached under HTTP cannot be used under HTTPS. The SSL connection must initially request its own dependent objects, which will then be available in the cache for future SSL requests.