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:

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

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:

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.

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

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.  

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).

Introduction

I recently made some changes to an ASP.NET web site on a shared hosting plan. There were some old web pages with HTML extensions that were replaced by newer pages with ASPX extensions. For example, I had an old page called clubteams.html and a new page called: teams.aspx. I wanted to make sure that visitors with links to the old pages would arrive at the new pages rather than seeing some obscure “not found” error.

This is a common enough issue and there are a number of ways to approach it on an ASP.NET website. But the devil is in the details, so they say, and it turns out that there are a lot of details involved in getting this right. In this series of blog entries, I’ll walk through the steps I took, share the lessons I learned and hopefully provide some answers for others seeking to do similar redirects in shared hosting environments.

Choosing an Approach

There are a number of methods for redirecting visitors from outdated web pages to their replacement pages. Here’s a list of some of the methods, grouped by required access level:

IIS Methods – Requires IIS Access

• IIS Page Specific Redirects
• IIS Custom Error Message Pages

ASP.NET Methods – No IIS Access Required

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

The ASP.NET methods only work for file-types that IIS passes to ASP.NET for processing. A typical IIS configuration does not hand off HTML pages to ASP.NET. Since the incoming URLs I wanted to redirect were going to be HTML pages, that pretty much seemed to rule out using ASP.NET processing.

I next looked at the IIS methods. The web host for the web site in question did not provide a direct way to configure IIS page-specific redirects, so that was out. The host did, however, provide a nice UI for configuring IIS custom error pages for a web site.

How would using a custom error page help me redirect old pages to new pages? IIS helps us out here by handing the custom error pages a query string that looks something like this:

404;http://www.yourserver.com:80/SomeBogusPage.html

That query string provides enough information to detect the visitor’s intended destination. From that, I can match against a list of obsolete pages and, where a mapping exists, redirect the visitor to the appropriate new page.

The added benefit of using error handling to do the redirects is that my site would also gain a much more user friendly error page than the default generic error pages provided by IIS or ASP.NET.

So I now had my approach mapped out. In my next blog entry in this series, I’ll describe how I implemented the IIS custom error page.