Some problems with the web.config 404 configuration under IIS7.5

This article presents an empirical problem with web.config configuration in an IIS environment. A few problems were encountered when adding the configuration 404 page in IIS7.5, which was recorded as follows:

1 began in < customError > Under the < error > Node configuration 404 does not work, as the program is running in IIS 7.5 integration mode, after MSDN and GOOGLE, found

Need to be in < system.webServer > Node configuration, we know < system.web > The node is the primary configuration node for the pre-iis7.0 version, due to the IIS pipe after II7.0

Trace processing is integrated with ASP.NET pipeline processing, which improves the processing performance of ASP.NET

< system.webServer > What changes need to be made in the node so that the program can fully take effect under the integration mode of IIS7, mainly including the following aspects:

(1) < modules > -- -- -- -- - the equivalent of < system.web > In the < httpModules >

(2) < handlers > -- -- -- -- - the equivalent of < system.web > In the < httpHandlers >

(3) < customError > Under the < error > - the equivalent of < system.web > In the < httpErrors >

If you have a custom httpModules or httpHandlers in your application, then points 1 and 2 are very important. Please refer to MSDN for details

Understand these, the configuration is not difficult, as follows:

<httpErrors errorMode="DetailedLocalOnly">
   <remove statusCode="404" />
   <error statusCode="404" path="/404.htm" responseMode="ExecuteURL" />
  </httpErrors>

Supplementary notes:

errorMode has three values, Custom, DetailedLocalOnly and Detailed, which means that the user and the server always display the customized page,

Only detailed error information can be displayed on the server side and always on the user and server side.

responseMode has three layers, File, ExecuteUrl and Redirect, which respectively represent the use of server-side static files, executable URL and URL steering.

Note: < httpErrors > with < customErrors > Is different, the former is mainly used to handle http related error messages, while the latter is mainly used to handle application-level error page redirection

The attached < customErrors > Some details:

Similarly, if Application_Error and < customerErrors > At the same time, there is also the issue of execution order. Because of the priority Application_Error event > < customErrors > Configuration item, so when an application-level error occurs, the code in the Application_Error event is executed first. If the Application_Error event calls the Server.ClearError () function, < customerErrors > defaultRedirect in the configuration section does not work because Exception has been cleared; If the Application_Error event does not call the Server.ClearError () function, the error page is repositioned to the URL page specified by defaultRedict to display a user-friendly error message.

Through the analysis of the above four error handling mechanisms provided by.NET, we can classify them from different perspectives, which is easy for us to understand and use.

1. Functional classification: for exception handling (Handling exceptions), Page_Error event and Application_Error event; The user error page redirect (Redirecting the user to an error page) is the ErrorPage attribute and < customErrors > Configuration items. 2. Classification from the scope of error handling: for page-level (Page level) error handling is Page_Error event and ErrorPage attribute; For application level (Application level) errors, the Application_Error events and < customErrors > Configuration items.

I hope this article is helpful to those of you who use IIS7.0 and IIS7.5 :)