Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

This is a browser agnostic question but we're testing with IE9.

One of the web apps our users visit is being randomly cached and changes aren't showing up when they should. No other site has this issue and we've worked with the vendor who claims it isn't happening to anyone else. If we use the developer toolbar and select "force refresh from server" everything updates correctly.

Instead of truly solving the issue our thought is to work around it by disabling cache for this specific site. However, we don't know how.

share|improve this question

The only proper way of disabling browser caching is by HTTP headers from the webapp itself. The HTTP 1.1 "Cache-Control" header alone should suffice for any post-year-2000 browser. But for extra protection the server can emit both HTTP 1.1 "Cache-Control" and HTTP 1.0 "Expires" headers together.

A hack'ish but sometimes seen way of handling cache invalidation is a "cachebuster" string in URLs from the server. The cachebuster is often timestamp based, and is added as a querystring to each HTML LINK to make the URL unique and only used once. Something like<timestamp+random_value>. This is ugly, and doesn't do anything the HTTP headers don't do far better. But it could be used as a hack for a limited audience (fx on an Intranet), or as an additional layer of protection together with proper HTTP headers.

AFAIK there is no way to selectively disable caching for a single site only from within Internet Explorer. One (bloody complicated) solution could be to install Varnish cache as an intermediary cache on your LAN, set Internet Explorer to use Varnish as HTTP proxy, and use the VCL language on Varnish to re-write the HTTP headers for this specific site only.

Honestly, I think your vendor is making a mistake here. I would suggest to install Fiddler2 for IE, or Firebug for Firefox, and look at the actual HTTP headers the webapp sends. Correlate that with Mark Nottingham's caching tutorial which I already linked to above -- I'm guessing the headers permit caching, or at least don't expressively forbid caching.

share|improve this answer

Make sure you set the proper expire headers. If you put the time in past, the content will not be cached. Check the time/date on the workstation where IS9 runs. See also:

share|improve this answer

If you cannot modify the contents of the web site in question, you can use a proxy server to modify the content enroute to your browser. This would allow you to change the expire headers.

share|improve this answer

If the website allows you to connect via HTTPS, then depending on your browser, you can disable caching encrypted pages.

In IE, this can be done thusly:

You can double check IE's settings in Internet Options->Advanced->Security->Do not save encrypted pages to disk.

share|improve this answer
He asked for a browser agnostic solution. – Mircea Vutcovici Apr 6 '11 at 21:29
@Mircea This IS a browser agnostic solution. I just provided a gratuitous example using IE. Many other browsers do have an option to disable caching SSL, but the settings are in different places. – JeffG Apr 6 '11 at 21:35
<meta http-equiv="PRAGMA" content="NO-CACHE">

You may wish to consider using random keys in the URL bar, this will also prevent caching within the browser.

share|improve this answer
This would work, IF GollyJer had the ability to modify the website. I gather he doesn't based on his question. – JeffG Apr 6 '11 at 21:28
Just to be precise, "random keys" do not effectively prevent caching. The browser and in-between caches may still store the response on disk. But next time the same file is requested, the random key will make the URL different, and thus the on-disk cached version will not be used. A new representation will be downloaded from the server, and possibly cached to disk. Additionally, the META PRAGMA tag is old and should not be used -- the recommendation is to use HTTP Expires and Cache-Control headers. – Jesper Mortensen Apr 6 '11 at 22:46

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.