Managed pipeline mode for IIS

IIS 7.0 supports two types of pipe modes:

(1) IIS 7.0 provides the latest integrated pipeline mode (Integrated),

(2) Classic pipe mode, classic pipe mode is provided by the previous version of IIS.

We can set the pipeline mode through the application pool, which is especially useful for IIS administrators because it allows one server to run only one mode, or two modes to run on a single server at the same time.

There is a significant difference between the Web. config files used by the two pipeline modes, and many Web. config files that work correctly in classic pipe mode do not work correctly in integrated pipeline mode. with AppCmd.exe, we can automatically convert the profile format in classic pipe mode to the configuration file format in integrated piping mode.

1. Classic Mode

In Classic mode in IIS 6.0, ASP. NET is an ISAPI that is added to IIS. 　　IIS 7.0 supports this mode for backwards compatibility. However, Classic mode lacks the features that many integration modes can provide. In Classic mode, IIS has its own pipeline, which can be augmented by creating an ISAPI extension, which is notoriously difficult to develop. ASP. NET runs as an ISAPI extension, just an integral part of the IIS pipeline.

This is a good explanation for the situation. Note that in this case, ASP. NET seems like an afterthought, and only works when IIS handles ISAPI extensions.

　　

You can determine which ISAPI handler to use by using the file name extension. For example, you can map files with the extension. aspx and. ascx to Aspnet_ Isapi.dll; and map files with an. asp extension to Asp.dll so that you can work with traditional ASP pages, and map files with a. php extension to Php.dll so that you can work with PHP pages, provided that you have installed Php.dll.

Additionally, in the Classic mode of IIS 6.0 and IIS 7.0, some features are duplicated. For example, error handling is a repeating feature because IIS can handle non-ASP. NET pages, and ASP. NET can handle all the pages that map handlers to aspnet_isapi.dll.

In IIS 6.0, we can map all file types to ASP., but there are some limitations. The biggest limitation is how to handle the default document: A default document can be processed only if it is specified as the default document in Global.asax or in an HTTP module. Some custom configurations require the use of Aspnet_isapi.dll to process all file types. IIS 7.0 can easily solve this problem.

Classic mode allows you to run an existing Web site without modifying the Web. config, so if you are using an IIS 6.0 server, including an IIS 7.0 server, Or, for some reason, the Web. config file cannot be converted to a Web. config file that follows the new syntax, so you can use Classic mode.

2. Integrated mode

　　With integrated mode, you can use ASP. NET as an integral part of IIS. The functionality of the IIS server is now divided into more than 40 modules, thus dividing the functionality of IIS and ASP into different components. Modules such as StaticFileModule, Basicauthenticationmodule, FormsAuthentication, Session, profile, and rolemanager are all part of the IIS pipeline.

Note that formsauthentication, Session, profile, and rolemanager are part of the original ASP, and are not related to IIS.

The IIS pipeline is interpreted using a module. These modules, which were originally part of ASP., are now an integral part of the IIS pipeline.

　　

The IIS pipeline provides more than 20 events that developers can use to extend the functionality of the Web server. In fact, we can replace modules in IIS 7.0 with custom modules by creating custom modules, updating applicationhost.config at the same time, using only custom modules, without using the built-in modules provided by Microsoft.

3. Differences in configuration between two modes

IIS 7.0 has made some modifications to the configuration files that Web developers can use to modify the content.

For example,,<system.webserver> section is such a modification, whether it is the Classic mode or Integrated mode can recognize the <system.webServer> section, while,<system.webserver> Sections can be set in either the ApplicationHost.config file or in the Web. config file. The <system.webServer> section can control both static and dynamic pages. Even in Classic mode, the,<system.webserver> section also plays an important role in helping Web developers set up different IIS configurations in the. config file.

In Integrated mode, HTTP modules and HTTP handlers are no longer defined in <system.web>, but are defined in <system.webServer>. 　　If you run a Web. config file that includes an HTTP module or an HTTP handler in Integrated mode, the invalidation will occur. Fortunately, Microsoft has detailed a 500.22 error message that explains how to migrate the Web. config file step-by-step.

Configuration <system.webServer> nodes in IIS 7.5

issue: the 404 page of Configuration <customError><error> node in IIS7.5 does not work

Analysis

The <system.web> node is the primary configuration node of the previous version of iis7.0, and after II7.0 IIS pipeline processing is integrated with ASP. ASP. NET processing performance is improved. Since the program runs in IIS7.5 Integrated mode, it needs to be configured in the <system.webServer> node, adding new <system.webServer> What modifications need to be made in the node to be fully effective in the integrated mode of the IIS7, mainly include the following aspects:

(1) <modules>-----equivalent to <system.web>

(2)

(3) <customError> <error>-----equivalent to <system.web>

Above three points, if you have custom httpmodules or httphandlers in your program, then the 1th and 2nd are very important, please contact MSDN for details.

Configuration

Add

Errormode has three values, respectively, custom, detailedlocalonly, detailed, meaning for the user and server side always display a custom page, only server-side display detailed error information, the user and the server side always display detailed error information.

Responsemode has a file, Executeurl, redirect three layers, respectively, the use of server-side static files, executable URLs, URL steering.

Note that:

<customErrors>

Similarly, if Application_Error and <customerErrors> exist at the same time, there is an issue of order of execution. Because of the priority Application_Error event > <customErrors> configuration Item, when an application-level error occurs, the code in the Application_Error event is first executed if Application_ The Server.ClearError () function called in the Error event,<customererrors> the defaultredirect in the configuration section does not work because exception has been cleared; The Server.ClearError () function is not called in the _error event, and the error page is relocated to the URL page specified defaultredict to display a friendly error message for the user.

through to. NET provides the above four kinds of error handling mechanism analysis, we can classify them from different angle, is easy for us to understand and use.

1, functionally classified: for exception handling (handling Exceptions) is Page_Error event and Application_Error event; User error page redirection (redirecting the user to an error Page) is the ErrorPage property and the <customErrors> configuration item.

2, from the scope of error handling: For page level error handling is the Page_Error event and ErrorPage property; for application level (application) error handling is the Application_Error event and <customErrors> configuration items.

Managed pipeline mode for IIS