Setting Far Future Expires Header In Code - ASP.NET

Question

Is there a way that I can Programmatically set an Expires Header in code with ASP.NET? Specifically I need to set it on an entire folder and all sub-folders, and the folder contains only static files (JavaScript, CSS, Images etc.) and not aspx files, so I can't just add some code to an aspx code-behind page_load.

I can normally set this directly in IIS. But the server is locked down by the client (I only have FTP access to web app directory for deployments), and getting the client to set the Expires Header on IIS would take an ice age (it's a public sector/government site).

I'm doing this for Front-End optimization reasons as per Yahoo's recommendations http://developer.yahoo.com/performance/rules.html#expires

Update: I've tried creating an HttpModule...

public class FarFutureExpiresModule : IHttpModule
{
    public void Dispose() { }

    public void Init(HttpApplication context)
    {
        context.BeginRequest += new EventHandler(context_BeginRequest);
    }

    void context_BeginRequest(object sender, EventArgs e)
    {
        HttpContext context = HttpContext.Current;

        string url = context.Request.Url.ToString();

        if (url.Contains("/StaticContent/"))
        {
            context.Response.Cache.SetExpires(DateTime.Now.AddYears(30));
        }
    }
}

Although this doesn't see to work. I've placed a breakpoint on the code, and it appers to run correctly. However, when I analyse the raw HTTP header information in Firefox, the expires value is not being set. Notice I'm using BeginRequest, but I've also tried hooking into PostReleaseRequestState and PreSendRequestHeaders and they don't seem to work either. Any ideas?

Update 2: OK so it seems because I'm running IIS6, HttpModules won't run for static files, only dynamic files (*.aspx etc.). Thanks to RickNZ's help I came up with the following IHttpModule:

public class FarFutureExpiresModule : IHttpModule
{
    public void Dispose() { }

    public void Init(HttpApplication context)
    {
        context.BeginRequest += new EventHandler(context_BeginRequest);
    }

    void context_BeginRequest(object sender, EventArgs e)
    {
        HttpContext context = HttpContext.Current;

        string url = context.Request.Url.ToString();

        if (url.Contains("/StaticContent/"))
        {
            context.Response.Cache.SetExpires(DateTime.Now.AddYears(30));
            context.Response.Cache.SetMaxAge(TimeSpan.FromDays(365.0 * 3.0));
        }
    }
}

...and it seems to work, but only in the built-in web server in Visual Studio, and in IIS7 (when in Intergrated Pipeline mode). A work colleague mentioned setting wildcard mappings on IIS6 to get HttpModules to work on static files, but if I have access to IIS6 I could just set the Far-Future Expires header directly and not bother with this HttpModule. Oh well!

Answer 1

If you're using IIS 7, the easiest way to do it would be to write an HttpModule that runs for static files in Integrated mode, and set the Expires and Cache-Control headers from there.

Update:

Your HttpModule should work, although I normally also call:

context.Response.Cache.SetMaxAge(TimeSpan.FromDays(365.));

Update 2:

With IIS 6, you would have to programmatically modify the metabase. It's possible, although it requires elevated permissions.

The only other option would be to write an ISAPI module in C++.

Answer 2

Even though YSLOW made the recommendation, you may also benefit from reading Mr. Atwood's article: YSlow: Yahoo's Problems Are Not Your Problems.

From the article:

Add an Expires Header (Weight: 11)

This isn't bad advice, per se, but it can cause huge problems if you get it wrong. In Microsoft's IIS, for example, the Expires header is always turned off by default, probably for that very reason. By setting an Expires header on HTTP resources, you're telling the client to never check for new versions of that resource-- at least not until the expiration date on the Expires header. When I say never, I mean it -- the browser won't even ask for a new version; it'll just assume its cached version is good to go until the client clears the cache, or the cache reaches the expiration date. Yahoo notes that they change the filename of these resources when they need them refreshed.

So I guess one of the takeaways is: suppose you change the contents of a master css file, but you don't also rename the css file. If you take Yahoo's recommendation, your end user won't get the updated version of the file you edited until the expiration date of the header. Are you comfortable with such a scenario?