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

This is the third 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 earlier posts in the series at the links below:

In the second post in this series, I discussed how I implemented an IIS custom error page to handle HTTP 404 errors.  This was a part of my solution for redirecting visitors from obsolete pages that were removed to new replacement pages for the same content. 

I ran into a glitch when I saw that IIS did not forward 404 errors for ASP.NET resources to the custom error page configured in IIS.  So it was clear that I was going to have to do some work on the ASP.NET side to handle any invalid resource requests ignored by IIS. 

 

Implementing an ASP.NET Custom Error Page

You may recall the ASP.NET redirecting options I mentioned from the first blog entry in this series.  Personally, I can’t recall my middle name without a cheat-sheet. So for those of you who are memory-challenged like me, here they are again:

ASP.NET Methods

  • Custom HTTP Handler
  • URL Rewriting
  • ASP.NET URL Mapping
  • ASP.NET Custom Error Pages

Since I already had an approach that leveraged custom error pages, it seemed that a good place to start would be to try to use ASP.NET’s built in support for custom error pages.

You configure ASP.NET custom error handling inside web.config in the customErrors tag.  The customErrors tag has a mode property which can be set to “Off”, “On” and “RemoteOnly”.  Visual Studio .NET, at least the 2005 version, creates web.config’s with the customErrors mode set as follows:

<customErrors mode="RemoteOnly" />

That tells ASP.NET to display custom errors for remote connections and display standard errors for localhost connections.  That set up ensures that remote users see an abbreviated error message without the stack-trace and other detailed information present in the non-custom messages.  For security reasons, not to mention aesthetics, you probably don’t want typical site visitors to see your stack-traces.  So it’s probably a good idea to leave the mode set to either “RemoteOnly” or “On”.

The customErrors tag allows you to map specific error codes to handler pages.  This is similar to how it’s done with IIS custom error pages.  I had already created a custom 404 error page for use with IIS custom error pages, so all I had to do was set up a mapping to the same error page for ASP.NET. Here’s what my customErrors tag looks like:

<customErrors mode="On"  defaultRedirect="~/errors/ServerError.aspx">
    <error statusCode="404"  redirect="~/errors/NotFound.aspx"/>
</customErrors>

The error tag allows you to create a mapping for a specific http error code. The defaultRedirect attribute allows you to map any HTTP error for which you don’t provide an error tag. In my case, I mapped the 404 error to my previously created NotFound.aspx error handler page.

I ran through my series of tests again, trying invalid URLS with HTML extensions, no extensions and ASPX extensions. This time, my custom error page was displayed in each case.

In the next blog post on this series, I'll get into the details of how I performed the redirects for the obsolete pages from the custom error page.