Properly Using Custom Error Pages in ASP.NET
Earlier this week I started with a rant about ASP.NET and Search Engine Optimization and was really tired of my platform being dissed as a good platform for optimized sites. One of the complaints raised by the article was the way ASP.NET handles custom errors. The complaint centers around two status codes being generated, first a 302 or temporary redirect is sent. Then a 200 status code is sent for a successful request. This is actually the proper way to indicate the custom error page process and I will explain why.
The basic premise behind custom error pages in ASP.NET is you as the developer can designate a page to be rendered when an unhandled exception is thrown by a request. You can also designate specific or specialized error pages be displayed when a specific status code, 404 for example is raised. The 404 status code is served when a resource cannot be found by the server.
How to Designate a Custom Error Page
The first thing I do when defining a custom error page is add the page to the site. The error page generally will consist of a notice to the user that something when wrong and a little reassurance that we (meaning I) will fix it as soon as we can. This is configured in the web.config file in the customErrors section. This element has two attributes, defaultRedirect and mode. The defaultRedirect attribute specifies the page that is displayed when an unhandled exception bubbles up through the chain of events.
<
customErrors defaultRedirect="
~/error.aspx"
mode="
RemoteOnly"
/> The mode attribute can be set to either On, Off or RemoteOnly. When set to On the custom error page is displayed both to remote computers and the local server computer. When it is set to Off no custom error page is displayed and the actual exception details a spewed onto the page for any visitor creating the exception. This is known as the Yellow Screen of Death because the text has a yellow background.
Finally RemoteOnly will only show the custom error page to remote users, but the actual exception messages to the local computer. This is very useful when you have access to the web server and are trying to track down a pesky bug.
Designating Custom Pages for Status Code Errors
One of the lesser known tricks with custom ASP.NET error pages is the ability to designate custom pages to be sent to the browser when specific status codes are generated. For example when a 404 or page not found status is generated this is an error. A 404 status code is sent in the response to the browser. In IIS you can designate a specific resource to be sent to the client or a generic 404 error will be displayed by the Browser.
ASP.NET allows you to designate custom pages for each status code. A status code is used to tell the web client about the request. A code of 200 means successful, 301 means permanently redirected, 404 means not found and 500 means there was an internal server error.
To add custom error pages for various status code you can add those to the customErrors element like this:
<
customErrors defaultRedirect="
~/error.aspx"
mode="
RemoteOnly"
> <
error statusCode="
403"
redirect="
default.aspx"
/> <
error statusCode="
404"
redirect="
default.aspx"
/> </
customErrors> Notice how I redirect the request to the home page for a page not found status. I do this as a catch all because I inherit many sites where the owners are not certain of what they actually have, or there are so many possible pages that it is a last ditched measure to get the visitor to something important on the site. If you set up your URL Rewriting engine properly you should be able to stop any of these types of things from happening.
Custom Error Handling in ASP.NET and Status Codes
So this leaves the final issue, the status codes that are sent up when a custom error page is generated in ASP.NET. The issues {insert name here} was having is a 302 status code is sent, followed by a 200 status code. Which is exactly how it should work! The 302 status code is a temporary redirect, so we are telling the client that for now this is where this page is going, but it should come back soon.
Yes we have an error, which should be handled very soon and this page will return to this location as expected, so please do not remove me from your index, cache or what have you.
Next a custom error page is successfully returned, hence the 200 or successful status code sent to the client. I keep saying client instead of browser because the real issue for Search Engine Optimization is what the search engine spiders actually process. In this case we tell them, oops I have an error so for the time being go here. That page is successfully processed and returned, just like we wanted.
So in summary, configuring custom error pages in ASP.NET is a pretty trivial task. The status codes generated by the custom error page process are correct and as expected. Once the error is corrected the search engines should revisit the page and get the proper content from the page, so a temporary redirect or 302 status code is the correct code to return.
