IIS 7.0 HTTP Error Pages
Internet Information Services (IIS) 7.0 adds some significant new functionality to the manageability and customization of error messages. The three main areas of improvement when compared to IIS 6.0 are Custom vs. Detailed error pages, better configurability of custom errors, and language-specific custom errors.
Custom vs. Detailed error
In IIS 7.0, the term “custom error” is used to describe the error information a regular user will see when navigating to your web site from a remote client machine. A “detailed error” is the kind that a local administrator or developer will see when browsing to the website locally on the IIS server itself.
Here is an example of the custom error page for an HTTP 404 response:
You’ll notice that the custom error page is simple and brief, with no extended information. The user is simply told that the page they requested could not be found.
Alternately, here is the detailed version of the HTTP 404 response page:
You’ll notice that the detailed page contains far more information than the custom version. By limiting the amount of information you send to remote users, you increase the security level of your IIS server; the less information about your server and the error condition that is sent to potentially malicious users, the better. Let’s look at the detailed error info more closely.
Error Summary
The information in the Error Summary section is essentially the same as the custom error page.
Detailed Error Information
This is where the new benefits of IIS 7.0’s detailed errors begin to shine. The detailed error section contains very low-level information about the error condition which administrators and developers can use to troubleshoot the problem.
Most Likely Causes and Things You Can Try
To help in the troubleshooting process, IIS 7.0 includes the most likely causes of the problem, and provides a list of steps you can try to resolve the issue.
Links and More Information
One of the coolest new features of IIS 7.0 is the “view more information” link in the detailed error pages. By clicking this link, the user will be taken to the Microsoft Knowledge Base article specific to the HTTP status code they just received. If a KB article doesn’t exist yet, the user will be taken to the general IIS 7.0 HTTP Status Code article (https://support.microsoft.com/kb/943891), and the IIS Support Team will be notified that an article for this particular HTTP status is needed.
Fort this example scenario, clicking the link will take us to the HTTP 404 article, KB942041
Configurability of Custom Errors
IIS 7.0 makes it easier to configure custom errors exactly how you want them. Added configuration options in the UI give administrators more flexibility and granularity; you can edit the existing configuration settings, or add completely new ones. Configuring error pages through the IIS Manager is done via the Error Pages feature in the main pane:
To edit the configuration of an existing customer error page, select the status code entry in the main pane, and choose Edit… in the Actions pane. The Edit Customer Error Page window will appear:
The Add Custom Error Page looks almost the same, except the fields are blank:
In both windows, you’re given the option to set the Response Actions accordingly. You can choose to send content from a static file (for example, create your own custom404.htm page and point to it in the file path directory), you can execute a URL on the site (let’s say you wanted an event log entry written any time someone encounters a specific error code…write an asp.net page that does the logging, and point to the page in the URL field!), or you redirect the user with an HTTP 302 status response.
It is important to note a change we’ve made in IIS 7.0 as compared to IIS 6.0 when it comes to unconfigured HTTP statuses. In IIS6, most of the HTTP statuses had an error page configured by default:
In IIS 7.0, we’ve reduced that list:
When it comes time for IIS to send an HTTP error response and the status doesn’t have an associated custom error configured, IIS 7.0 will send a short one-line message. For example, if you remove the default custom error for an HTTP 404 status and request a non-existent page, the error you get back is:
These one-line messages are hard coded and cannot be changed. They do, however, get localized and will be sent in the language that the server is configured for.
Language-specific Custom Errors
When a web browser sends an HTTP request to a web server, it has the option of including an “Accept-Language” request header. This header tells the server what language the client would prefer to receive its response in.
IIS 7.0 takes into account a request’s Accept-Language header and will attempt to send the custom error page that corresponds to the language in the header. For example, if a client makes a request for a non-existent page and its request included an Accept-Language header with a value of “en-us”, by default the error page that gets sent back to the client in response is “c:\inetpub\custerr\en-us\404.htm”. Note the “en-us” in the file path.
However let’s say that the user is in France and their browser sends an Accept-Language header of “fr-FR”. To send the French version of the 404.htm page as a response, you would install the Windows Language Pack for French; this creates the C:\inetpub\custerr\fr-FR directory. Now the error page that would be sent is C:\inetpub\custerr\fr-FR\404.htm.
More Information
More information on IIS 7.0 HTTP errors can be found at the following locations:
How to Use HTTP Detailed Errors in IIS 7.0
https://learn.iis.net/page.aspx/267/how-to-use-http-detailed-errors-in-iis7/
Configuring HTTP Error Responses in IIS 7.0
--- > Credit goes to Mike Laing for this post.
Comments
Anonymous
May 27, 2008
The Article ends with "> Mike", I'd guess that is Mike Laing or Mike Coleman . but the post script says "Saurabh Singh". I am confused about who wrote this article and who is taking credit for it .Anonymous
May 28, 2008
Hi Robin, hope the current wording clears the confusion :-) Cheers!Anonymous
April 08, 2009
I love the custom language specific error pages but seem to be struggling to find a pre-prepared pack of alternative (european) language error pages. I would have thought they must be avilalbe in an SDK somewhere...