Redirects Using 404 Error Handling in ASP.NET 2.0 on Shared Hosting (Part 2)

This is the second in a series of blog entries on using 404 error handling to redirect obsolete HTML pages to newly created ASPX pages.  You can read the first post in the series at the link below:

Redirects Using 404 Error Handling in ASP.NET 2.0 on Shared Hosting - Part 1

In that last post, I enumerated some of the options for performing redirects on ASP.NET web sites.  Do to limitations in the ASP.NET options, I decided to handle the redirects in IIS by setting up an IIS custom error page to trap HTTP 404 errors.  In the code-behind for the error page, I will examine the requested URL (that is passed to the IIS custom error page by IIS) and then perform a redirect when the errant URL points to an old page that has been replaced by a newer page.

 

Implementing an IIS Custom Error Page

To set up an IIS custom error page, you first need to create the web page you want visitors to see when a specific error occurs. In this case, I wanted to provide a page to handle 404 errors. 404 errors occur when a visitor requests a page (or other resource) that doesn’t exist on the web site.

By default, when a 404 error occurs on an ASP.NET web site, a default, generic error page is displayed by either IIS or ASP.NET. ASP.NET provides the error message for all resource types handed to it by IIS. IIS provides the error message for all other, non-ASP.NET, resource types.

Here’s what the default generic messages look like:

IIS Generic 404 Error Page

ASP.NET Generic 404 Error Page

ThePageCannotBeFound TheResourceCannotBeFound

To get started, I created a new folder called /errors into which I would place my custom error handling pages. I then created a page to handle 404 errors called NotFound.aspx. I like to do things a step at a time, so I didn’t try to create any redirect logic at this point; I just threw some basic content into NotFound.aspx that would clearly distinguish it from the default error pages.

Next I went into the host providers control panel applet and configured IIS to redirect 404 errors to the path for my custom error page: /errors/NotFound.aspx. With that done, I was ready to test things out.

I tried visiting the web site with a URL like: http://www.myserver.com/NoSuchPage.html. I expected to see my custom error page content appear and was happy to see that it did. I also tried http://www.myserver.com/NoSuchPage, not providing any extension at all. That worked as well. I was getting pretty psyched – it looked like this might be a pretty simple exercise after all.

Then I tried http://www.myserver.com/NoSuchPage.aspx (note the extension). This time, instead of seeing my custom error page, I saw the generic ASP.NET error page. Aw, crud. WTF was going on here? (Pardon my acronymical French)

I tried a page with an ASMX extension and that also produced the generic ASP.NET error page. It appeared that errant ASP.NET resources requests were not being redirected to my IIS custom error handler page. This was unexpected. I was working on the assumption that since all resource requests flow through IIS first, IIS would detect their non-existence and redirect any invalid request to an IIS custom error page. Apparently my assumption was off the mark. I just hate when that happens, as unusual as it is. Smile 

As it turns out, IIS hands off ASP.NET resources prior to validating the existence of the resource so IIS never gets a chance to redirect to the custom error page. While I wasn’t entirely happy about this, it does make sense from a purity of modularity standpoint. IIS is acting like a dumb web server and leaving the intelligence of handling ASP.NET file-types to ASP.NET.

With this realization, it looked like I was going to have to use one of the ASP.NET methods to supplement the IIS Custom Error Page solution.  In my next post, I'll get into the details of using ASP.NET Custom Error Pages (the method I chose to handle things on the ASP.NET side).