Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're suddenly having problems with some of our sites having old versions of .css and .js files show up in the browser. Generally, these problems go away, when the user clears cache in the browser.

Is there something we can do either in the code or in IIS7, to convince the browser to not used the cached files?

In our weirdest case, we have one customer whose users hit our site, and get an old version of a js file. They clear cache, load the page, get the current version, and the page runs fine. Then they load the file again, and suddenly have the old version, again.

Any ideas as to how that might be happening? I can think of three:

  1. The browser is somehow holding on to the old version, when we clear cache, and is putting it back in the cache, before the second page load.
  2. One of our servers has an old version of the file, and while the first page load after a clear cache pulls it from one of the servers with the current version, second and subsequent page loads pull it from the server that has the old version.
  3. The first load after a clear cache goes straight to our servers, while subsequent loads pull the file from the cache on the customer's web proxy.

I have to say, all three of those scenarios seem outlandishly unlikely, but it's a repeatable behavior.

Any ideas?

share|improve this question
Is your IIS configured to send an Expires header? (HTTP Response Headers feature, Set Common Headers option) – Shane Madden Apr 12 '12 at 0:27
That seems to me to be exactly the wrong approach. It's not that we want them to download the file again, if what they have in cache is more than x days old. We want them to download the file if what they have isn't identical to what is on the server. – jdege Apr 12 '12 at 14:43
Yeah - what I'm saying is that if the Expires header is set, it may be the cause of your issues. Can you examine the headers in the browser connection to see if there's Expires headers, or if the browser's relying on just ETag and timestamp headers for cache determination? – Shane Madden Apr 12 '12 at 14:48
I just grabbed the headers from one of the .js files that had been showing the problem. It has no "Expires" header. "Last-Modified" and "If-Modified-Since" look right, "Cache-Control" is "max-age=0". – jdege Apr 12 '12 at 16:10
That should be fine, then! Any commonality on which browsers display the issues, or is it all of them? And, any way you can get your hands on a messed up client browser to do some debugging? – Shane Madden Apr 12 '12 at 16:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.