Odd caching behaviour by browsers when using ASP.NET CSS Bundles

Question

Im really to confused as to whats going on here.

It seems the (System.Web.Optimization.)Bundle library puts a filesystem watcher on all the files it has bundled up. Whenever there is a change (say for example I tweak the contents of a CSS file), it rebuilds the bundle.

I've seen this work by making requests to the URL of a CSS bundle in Fiddler, with which it works by regenerating the CSS bundle faultlessly, 100% of the time.

However, in both Firefox and Chrome, and only sometimes, it doesn't *appear* to be hitting the webserver, and continues serving me the old, unmodified CSS.

The weird thing is, even after doing a full cache refresh (ctrl+shift+r), and even going into chrome and deleting *all* cached data, it still serves me exactly the same, old CSS file.

This makes me think the fault / issue is actually within the Bundle library -maybe fiddler is passing different request headers or something, that make the Bundle handler to behave inconsistently?

Appreciate any help with this matter as its been going on for days.

Edit: So i've put together the following code which seems to be working

...
var styleBundle = new Bundle(virtualPath, new NoCacheTransform());
...


public class NoCacheTransform : IBundleTransform
{
    public void Process(BundleContext context, BundleResponse response)
    {
        context.EnableOptimizations = false;
        context.UseServerCache = false;
        response.ContentType = "text/css";//text/css; charset=utf-8
        response.Cacheability = HttpCacheability.NoCache;
    }
}

A couple of those property assignments might not be necessary, but its more of a head up.

Answer 1

My guess is this is a bug. We're seeing similar behaviour; and there are various bugs that seem to describe this open. Sadly the source is not public, and MS were unable to repro this when I contacted them; so it's gone unfixed :(

https://aspnetoptimization.codeplex.com/workitem/120 https://aspnetoptimization.codeplex.com/workitem/96 https://aspnetoptimization.codeplex.com/workitem/114

Answer 2

It might help to fingerprint the bundle? Refer to http://madskristensen.net/post/cache-busting-in-aspnet for more info.