httpErrors, customErrors and 404s

Came across an interesting scenario today. Well actually, it started yesterday, it just took me ages to figure out whats going on.

Ok, the scenario; We have an ASP.NET application, that uses custom error pages, and also a rather robust logging framework. Here’s how we have our custom errors configured:

Now, since migrating our website to the behemoth that is IIS7, we can now configure custom errors at the web server, through httpErrors:

Now typically our custom error page will respond with a status code of 404. Although this is normally not required because the customError handler of ASP.NET will handle this for you, if you visit the page directly, you really should set the 404 response code, if only to ensure that the page doesn’t get indexed by search engines.

In our PageNotFound.aspx page, we log our 404 to let us know what happened, but we are finding we are actually getting two notices from the page.

public partial class PageNotFound : Page {

    #region Methods
    public void Page_Load() {
            Response.StatusCode = 404;
            Logger.Log(...);
    }
    #endregion
Code language: PHP (php)

}
So, why is this happening?

Turns out, when ASP.NET has finished processing our PageNotFound.aspx request, IIS then kicks in and realises we have returned a 404, so it’s own error handling takes over. In our current configuration, we’re telling it to execute the url ‘/PageNotFound.aspx’. That sorts that one out then, IIS is executing the same page on the same request, which means the page processes twice, hence the two responses.

Now, we can’t change the responseMode of the IIS custom error entry because the alternative settings won’t work. ‘File’ won’t allow us to process the PageNotFound.aspx file with ASP.NET, and Redirect ends up creating a cyclic redirect, as the redirect creates a whole new request, which again reports a 404, which IIS then performs anothe redirect and yadayadayada.

I finally found the answer, its a setting for httpErrors called existingResponse. Now, when this setting is set to ‘PassThrough’, the error module will determine if the response it received from earlier in the request pipeline already has a response body. If it does, it simply returns the existing response, instead of performing the custom action:

So now, we’re still performing our custom error handling correctly, and the good news is, we correctly process the page once.