Cache Control Headers with IIS 7.5

Question

I'm trying to wrap my head around client side (web browser) caching and how it works in relation to IIS 7.5 cache control headers.

In particular:

1. If we want to force clients to reload cached resources, how must IIS be configured?

2. Do we need to set expire web content immediately if the resources on the server have a more recent Modified Date (or ETag value)?

3. Right now we're not setting any cache headers. So if I set a cache header of no-cache (which I think is the equivalent of expire web content immediately) will that force the web browser to obtain a new version of a particular file. Or will the browser only request a new version after it deems its current copy to be stale and then from that point forward not cache it?

Would a best practice be to set a cache control flag of 1 week, then 8 days before I know I am going to make a change set the cache control down to for instance 30 minutes?

But if I do that and then need to immediately expire an item from users caches because there was an issue with it how do I do that?

Solution

One way to understand client/user agent caching is to view the browser as implementing an intermediate cache for itself (which in fact it does, addressed by Cache-Control: private). This abstracts all the terminology to simple patterns of request and response, and in most cases the browser cache behaves the same as a proxy or intermediate cache. Keeping this in mind is helpful when reading the authoritative documentation on the subject in IETF RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.

1. Set the "Expires" header to "Immediately" (which sends Cache-Control: no-cache) as described at http://technet.microsoft.com/en-us/library/cc770661(v=ws.10).aspx and http://msdn.microsoft.com/en-us/library/ms689443(v=vs.90).aspx.

2. No. If you don't send any Cache-Control headers, IIS should send the latest version of the resource and a client should recognize that from either the Last-Modified header or the ETag.

3. Your first statement is correct: sending no-cache will instruct the client to request the resource every time, even if it has already cached it. Some clients misbehave and cache such resources anyway, but you can also use must-revalidate to ensure that it gets a fresh copy

As for best practices, how long you cache depends on your application and users' needs. You can always send Cache-Control: must-revalidate to solve the issues mentioned, so there is no need to globally change your cache expiration.