Mini-Tweek: customErrors in ASP.NET

As of the latest .NET Service Pack (3.5 SP1, 3.0 SP2, 2.0 SP2) there is a new attribute for the <customErrors> element of your web.config, redirectMode.  It has 2 settings, ResponseRedirect (default, legacy functionality), and ResponseRewrite (new functionality).  The ResponseRedirect setting causes the custom error redirection to work just like all of the previous versions where the server performs a redirect and all state (i.e. exception stack) information is lost.  The only way to get around this previously was to add a Server.Transfer() to the Application_Error method of your global.asax, which rendered the <customErrors> section useless as you had to hard code the URL in global.asax.cs.

This new setting cases the server to do a Server.Transfer() to the defaultRedirect page.  This means that the page state (including exceptions) are intact and that you can use the configurability of the <customErrors> section again.  I recently needed this functionality on a project where I'm the lead developer, but the client wants to write most of the SQL code.  Since he is not local to the test server, the RemoteOnly setting doesn't help.  Since this functionality needs to go on the production server as well, I created a custom error page and added just the error text to the page.  It's just enough information to let him know why the site is failing, but doesn't give hackers any useful information.

Published Sat, Jul 4 2009 07:38 PM by Bill Bosacker

Leave a Comment

(required) 
(required) 
(optional)
(required)