Lesson learned: HTTP modules can also affect WebResource.axd

HTTP modules can be very useful. In fact, I love them. The scope of this post is unfortunately not to explain what they are or what they do. If you're not familiar with what a HTTP module is, get an overview here and see how to create one here.

ASP.NET features some built in handlers: WebResource.axd and ScriptResource.axd. You'll see requests to these in any ASP.NET application, as they're used to serve builtin scripts for e.g. postback or client side form validation. By default, the ASP.NET application will configure these to expire from cache after a year.

Today I discovered a side effect I had not thought about. HTTP modules are loaded by the application, and are hooked into the event pipeline for each and every request handled by the ASP.NET application. In fact, this also includes requests to the WebResource.axd and ScriptResource.axd handlers!



Say you make an HTTP module that sets the cache policy for all responses — this is a nice trick to enforce a coherent cache policy for all pages across a website. Well, you just enforced your policy upon the built in handlers, which was probably not what you wanted. By default their response will be cached for an entire year, and reducing their time to live will obviously affect the load on your servers. You might even expire them immediately, forcing users to reload unchanged scripts on every page load (I know someone who did).

So, keep in mind that HTTP modules are also run for the built in handlers — or be prepared to taste the side effects.

As a final note, since we're discussing WebResource.aspx and caching: Make sure that the ASP.NET application is run with the <compilation debug="false"> setting, or else the framework will ensure that built in resources are not cached. ScottGu explains why on his blog, and one of the ASP.NET engineers elaborate further on the details of this setting on her blog.

To verifiy that the cache setting for the WebResource.axd is sane, use e.g. the Fiddler tool to inspect the response headers. You should see a date header with the current date, and an expires header with a date a year into the future, like this:

Date: Mon, 08 Nov 2010 14:57:24 GMT
Expires: Tue, 08 Nov 2011 14:57:24 GMT


Happy caching.