Hard refresh and XMLHttpRequest caching in Internet Explorer/Firefox

Question

I make an Ajax request in which I set the response cacheability and last modified headers:

if (!String.IsNullOrEmpty(HttpContext.Current.Request.Headers["If-Modified-Since"]))
{
    HttpContext.Current.Response.StatusCode = 304;
    HttpContext.Current.Response.StatusDescription = "Not Modified";
    return null;
}
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.Public);
HttpContext.Current.Response.Cache.SetLastModified(DateTime.UtcNow);

This works as expected. The first time I make the Ajax request, I get 200 OK . The second time I get 304 Not Modified .

When I hard refresh in Chrome (Ctrl+F5), I get 200 OK - fantastic!

When I hard refresh in Internet Explorer/Firefox, I get 304 Not Modified . However, every other resource (JS/CSS/HTML/PNG) returns 200 OK .

The reason is because the "If-Not-Modified" header is sent for XMLHttpRequest's regardless of hard refresh in those browsers. I believe Steve Souders documents it here .

I have tried setting an ETag and conditioning on "If-None-Match" to no avail (it was mentioned in the comments on Steve Souders page).

Has anyone got any gems of wisdom here?

Thanks, Ben

Update

I could check the "If-Modified-Since" against a stored last modified date. However, hopefully this question will help other SO users who find the header to be set incorrectly.

Update 2

Whilst the request is sent with the "If-Modified-Since" header each time. Internet Explorer won't even make the request if an expiry isn't set or is set to a future date. Useless!

Update 3

This might as well be a live blog now. Internet Explorer doesn't bother making the second request when localhost. Using a real IP or the loopback will work.

Answer 1

Prior to IE10, IE does not apply the Refresh Flags (see http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx ) to requests that are not made as a part of loading of the document.

If you want, you can adjust the target URL to contain a nonce to prevent the cached copy from satisfying a future request. Alternatively, you can send max-age=0 to force IE to conditionally revalidate the resource before each reuse.

As for why the browser reuses a cached resource that didn't specify a lifetime, please see http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

Answer 2

The solution i came upon for consistent control was managing the cache headers for all request types.

So, I forced standard requests the same as XMLHttpRequests, which was telling IE to use the following cache policy: Cache-Control: private, max-age=0.

For some reason, IE was not honoring headers for various requests types. For example, my cache policy for standard requests defaulted to the browser and for XMLHttpRequests, it was set to the aforementioned control policy. However, making a request to something like /url as a standard get request, render the result properly. Unfortunately, making the same request to /url as an XMLHttpRequest, would not even hit the server because the get request was cached and the XMLHttpRequest was hitting the same url.

So, either force your cache policy on all fronts or make sure you're using different access points (uri's) for your request types. My solution was the former.