If you've read and followed up on my previous posts about handling errors, you might have found yourself pulling out your hair when you discovered that your error handling went south again when you changed your target ASP.NET framework from 2.0 to 3.5/4.0 (applies to WebForms only of course). So here I am to save your day again (and yes, I wasted an entire Friday evening figuring this one out - good times).
In a nutshell, upgrade to 3.5 and your awesomely handled 500 and 404 errors start going back to 302 and 200 redirects the ol' fashioned (and completely idiotic) ASP.NET way of doing things. Of course, if you are like me, you'd waste an entire evening on it. But fortunately, you're not so you won't.
There's two issues/solutions:
- As of ASP.NET 3.5 there's now a redirectMode="ResponseRewrite" setting for your customErrors setting in your Web.config (yeah!). Put it in and you're halfway there (the default is the aforementioned moronic "ResponseRedirect"). Now your:
Context.Response.Clear();
Context.Response.TrySkipIisCustomErrors = true;
Context.Response.StatusCode = statusCode;
Context.Response.Status = status;
Context.Server.Transfer(errorPage, false);
is back firing on all cylinders again.
- Except that your 404s are fine now, but your 500 errors return your error page twice in the body of your error page! Genius that I am, I went back to my experiences with IIS 6 and wrapped error pages and figured out that IIS 7/7.5 was sending back "its own" error page and then my server transfer was getting tacked on as well. Again, this does not effect 404s - I'm guessing because we clear the error (see previous post). So remove the Server.Transfer for non-404s and we're golden again.
In summary, for IIS 7/7.5 and .NET 3.5/4.0, use the following as a starting point for your Global.asax.cs or, better yet, an error module (for good measure figure out how it could be all tested):
private readonly static ILog Log = LogManager.GetLogger(typeof(Global));
private string _errorPageLocation;
private string _error404PageLocation;
protected void Application_Start(object sender, EventArgs e)
{
// Wire up log4net database connection string if desired.
if (Log.IsInfoEnabled)
Log.Info("Log4Net initialized - Ignore.");
}
protected void Application_Error(object sender, EventArgs e)
{
InitConfigurationFields();
Exception exception = Context.Server.GetLastError();
if (exception is HttpUnhandledException)
if (exception.InnerException != null)
exception = exception.InnerException;
if (exception is HttpException)
{
var ex = (HttpException)exception;
var statusCode = ex.GetHttpCode();
if (statusCode == 404)
{
ServerTransfer(_error404PageLocation,
"404 Not Found", statusCode);
return;
}
}
Log.Error("Unhandled error caught in error module.", exception);
//Todo: Any way to get the correct status statement for a specifc code?
//Hard-coding all to "500 Internal Server Error" here.
ServerTransfer(_errorPageLocation, "500 Internal Server Error", 500);
}
/// <summary>
/// Gets configuration fields for database connection (if applicable),
/// and customError redirects.
/// </summary>
private void InitConfigurationFields()
{
var section = WebConfigurationManager.GetSection("system.web/customErrors");
if (section != null && section is CustomErrorsSection)
{
var customErrorsSection = (CustomErrorsSection)section;
_errorPageLocation = customErrorsSection.DefaultRedirect;
var error404 = customErrorsSection.Errors["404"];
if (error404 != null)
_error404PageLocation = error404.Redirect;
}
if (string.IsNullOrEmpty(_errorPageLocation))
throw new NullReferenceException(
"customErrors DefaultRedirect must be specified in Web.config.
...For i.e. ~/error.aspx"
);
if (string.IsNullOrEmpty(_error404PageLocation))
throw new NullReferenceException(
"customErrors 404 statusCode redirect must be specified
...in Web.config. For i.e. ~/page-not-found.aspx"
);
}
private void ServerTransfer(string errorPage, string status, int statusCode)
{
// If customErrors is off, just let ASP.NET default happen.
if (Context == null || !Context.IsCustomErrorEnabled)
return;
// Want the error around so that we can provide a little more
// descriptive message to end user in error page.
// However, for 404 errors (only!), not clearing the error causes IIS7 to
// still hijack the process and the custom 404 error page.
if (statusCode == 404)
Server.ClearError();
Context.Response.Clear();
Context.Response.TrySkipIisCustomErrors = true;
Context.Response.StatusCode = statusCode;
Context.Response.Status = status;
// For .NET 3.5, doing a Server.Transfer combined with customErrors
// redirectMode="ResponseRewrite" returns the error page body *twice*.
if (statusCode == 404)
Context.Server.Transfer(errorPage, false);
}
Peter was approached last year by the editor, Beth Thomsett-Scott, who has gathered together chapters by experts on nine different programming languages that librarians might need to know more about.