This can be a nightmare to deal with, as you cannot ask all users of a web site to change their browser settings.

One workaround is to use a ‘cache buster’ parameter in your GET request. Something like this:

var urlToFetch = 'whatever.php?randNum=' + new Date().getTime();

This works very well, but can have drawbacks, depending on your server setup. For example, if your application server sits behind a caching layer, you wouldn’t want the URL to be different every time for idempotent requests, as the cached version would never get used, and so your application server would get a direct hit every time.

One way around this without using to parameters is to set the ‘Cache-Control’ response header to direct the browser how to cache the response.

The ‘Cache-Control’ header can have various values, one of which is ‘no-cache’. This tells the browser that it should not cache the response, so the next time the same URL is requested, new content will always be sent (as there is no previous version in the browser’s cache).

This is how we do it using Groovy:

response.addHeader "Cache-Control", "max-age=0,no-cache,no-store"

So really, which method you use boils down to this: If you know that the cache buster will have a performance hit on your setup, then don’t use it, otherwise use whichever method you prefer.

Also, as a developer, I can highly recommend changing your IE cache settings to ‘Every visit to the page’.

We’re finding that with some of our automated testing, IE 7 still caches the odd file now and then. To get around this, we have modified our ‘Cache-Control’ header to include two non-standard properties, ‘post-check’ and ‘pre-check’, and added an ‘Expires’ header as well:

response.addHeader "Cache-Control", "max-age=0,no-cache,no-store,post-check=0,pre-check=0";
response.addHeader "Expires", "Mon, 26 Jul 1997 05:00:00 GMT"

Consider the following CSS and HTML code snippets that set up the problem with a link contained within a div that has an alpha transparency filter applied to it:

<style type="text/css">
.opaque { background: url(images/alphaTransparent.png) transparent no-repeat left top; }
</style>
<!--[if IE 6]>
<style type="text/css">
.opaque {
	background-image: none;
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true,sizingMethod=crop,src=images/alphaTransparent.png);
}
</style>
<![endif]-->

...
<div id="parent" class="opaque">
    <span id="child">Lorem <a href="http://www.codecouch.com">ipsum</a> dolor.</span>
</div>
...

The parent element has a class opaque applied to it which puts an image on the background of the element. In Internet Explorer 6 only, the background image is removed and the proprietary filter property is used. The link inside the child span is no longer clickable in Internet Explorer 6.

Make sure the parent element (the element with the filter applied to it) doesn’t have the position property set on it, and the child element (the element with the link in it) has to have relative position.

The following addition to the above code will make the link clickable:

<!--[if IE 6]>
<style type="text/css">
#child { position: relative; }
</style>
<![endif]-->

Since it only has to apply for Internet Explorer 6, the “fix” can be enclosed within the conditional comment that targets just that browser. This doesn’t require any javascript to work (unlike other solutions that have been posted) and degrades properly.