How To Disable Custom Errors At Webroot


A custom error is a page defined by the developer that gets displayed instead of the raw exception and stack trace information. This is commonly done for "File Not Found" pages, but can be defined for many exceptions.

It allows displaying a more user friendly message to the user and stops the application from leaking internal application information which could lead to a security risk.


Using a Custom Error Page

Every web application should have a custom error page. It provides a more professional-looking alternative to the Runtime Error YSOD, it is easy to create, and configuring the application to use the custom error page takes only a few moments. When an unhandled exception occurs in an ASP.NET application, the user is shown one of three error pages: the Exception Details Yellow Screen of Death; the Runtime Error Yellow Screen of Death; or a custom error page. Which error page is displayed depends on the application's configuration and whether the user is visiting locally or remotely. The default behavior is to show the Exception Details YSOD to local visitors and the Runtime Error YSOD to remote visitors.

While the Runtime Error YSOD hides potentially sensitive error information from the user visiting the site, it breaks from your site's look and feel and makes your application look buggy. A better approach is to use a custom error page, which entails creating and designing the custom error page and specifying its URL in the section's defaultRedirect attribute. You can even have multiple custom error pages for different HTTP error statuses.

The custom error page is the first step in a comprehensive error handling strategy for a website in production. Alerting the developer of the error and logging its details are also important steps. The next three tutorials explore techniques for error notification and logging.

Notifying Developers and Logging Error Details

Errors that occur in the development environment were caused by the developer sitting at her computer. She is shown the exception's information in the Exception Details YSOD, and she knows what steps she was performing when the error occurred. But when an error occurs on production, the developer has no knowledge that an error occurred unless the end user visiting the site takes the time to report the error. And even if the user goes out of his way to alert the development team that an error occurred, without knowing the exception type, message, and stack trace it can be difficult to diagnose the cause of the error, let alone fix it.

For these reasons it is paramount that any error in the production environment is logged to some persistent store (such as a database) and that the developers are alerted of this error. The custom error page may seem like a good place to do this logging and notification. Unfortunately, the custom error page does not have access to the error details and therefore cannot be used to log this information. The good news is that there are a number of ways to intercept the error details and to log them.

HTTP Errors

The element allows you to configure custom error messages for your Web site or application. Custom error messages let you provide a friendly or a more informative response by serving a file, returning another resource, or redirecting to a URL when visitors to your site cannot access the content they requested. For example, you might want to customize each of the error message pages for your Web site to have the same look and feel as the rest of your site.

The element contains a collection of elements, each of which defines an error message that IIS uses to respond to specific HTTP errors. You can add custom error messages to IIS by adding an element to the element in the Web.config file for your site, application, or URL. Each element uses the responseModeattribute to specify whether IIS serves static content, dynamic content, or redirects to a separate URL in response to an error. You can use the element to remove a specific error message from the collection of error messages your site or application inherits from a higher level in the IIS configuration hierarchy. Also, you can use the element to remove all HTTP error messages from the collection of HTTP error messages that your site or application inherits.

The element also contains attributes that configure IIS 7 to process requests that cause errors. TheexistingResponse attribute defines what IIS 7 does to an existing response when the server returns an HTTP error status code. The defaultPath attribute defines the path to a customer error page if you choose specify File for the responseMode attribute in an element.

The detailedMoreInformationLink attribute specifies a link to more information about a particular error. The element also can contain an errorMode attribute that you can use to control the level of detail that IIS returns to a browser when an HTTP error occurs. You can set the errorMode attribute to DetailedLocalOnly, which is the default setting, or you can set it to Custom or Detailed. If you specify DetailedLocalOnly, or if you do not specify an errorMode value, IIS returns detailed error information only to the browser on the local server and a custom error message to a browser on an external computer. If you set the errorMode value to Custom, IIS returns only custom error messages to all requesting browsers. If you set the errorMode value to Detailed, IIS returns detailed error information to all requesting browsers. The default DetailedLocalOnly value allows you to troubleshoot HTTP errors on the local server while not exposing sensitive information to external browsers.

By default, IIS serves error messages defined in files stored in the %SystemRoot%\Help\IisHelp\Common folder. You can create a custom error message for users and configure IIS to return this page whenever it encounters a specific HTTP error on your site.