• Choose a category
• All
• Classic-Fiction

Using Custom Error Pages

Overall, whatever your choice is for the mode attribute, all users have a good chance to be served a rather inexpressive and uninformative error page. To display a more professional, friendly, and apologetic page that has a look and feel consistent with the site, you set web.config as follows. Figure 7-4 gives an idea of the results you can get.

defaultRedirect="/GenericErrorPage.aspx" />

Figure 7-4. A more friendly error page.

Whatever the error is, ASP.NET now redirects the user to the GenericErrorPage.aspx page, whose contents and layout are completely under your control. This look is obtained by adding an optional attribute such as defaultRedirect, which indicates the error page to use to notify users. If mode is set to On, the default redirect takes on the standard error pages for all local and remote users. If mode is set to RemoteOnly, remote users will receive the custom error page while local users (typically, the developers) still receive the default page with the ASP.NET error information.

In most cases, the custom error page is made of plain HTML so that no error can recursively be raised. However, should the error page, in turn, originate another error, the default generic page of ASP.NET will be shown.

Note

When a default redirect is used, the browser receives an HTTP 302 status code and is invited to issue a new request to the specified error page. This fact has a key consequence: any information about the original exception is lost and GetLastError, which is called from within the custom error page, returns null.

Handling Common HTTP Errors

A generic error page invoked for each unhandled exception can hardly be context-sensitive—especially if you consider that there’s no immediate way for the page author to access the original exception. We’ll return to this point in a moment.

In addition to redirecting users to a common page for all errors, ASP.NET enables you to customize pages to show when certain HTTP errors occur. The mapping between error pages and specific HTTP status codes is defined in the web.config file. The section supports an inner tag, which you can use to associate HTTP status codes with custom error pages.

...

The element indicates the page to redirect the user to when the specified HTTP error occurs. The attribute statusCode denotes the HTTP error. Figure 7-5 shows what happens when the user mistypes the name of the URL and the error HTTP 404 (resource not found) is generated.

Figure 7-5. A custom page for the popular HTTP 404 error.

When invoked by the ASP.NET infrastructure, pages are passed the URL that caused the error on the query string. The following code shows the code-behind of a sample HTTP 404 error page:

public partial class Error404 : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

var errPath = "No error path information is available.";

var o = Request.QueryString["AspxErrorPath"];

if (o != null)

errPath = o;

// Update the UI

ErrorPath.InnerHtml = errPath;

}

}

If you have custom error handling and a global application handler in place, you should not clear server errors. The sequence in which handlers are invoked is this: page, application, ASP.NET runtime with configured redirects.

Important

In light of some security vulnerabilities discovered recently, returning a different output for different HTTP errors might help attackers to find out valuable information about the system. For this reason, it is recommended that you set a default redirect page and avoid adding error-specific