Analysis and understanding of IIS 7 managed pipe mode classic integration mode

IIS 7.0 supports two MPs queue modes: one is the latest integrated MPs queue mode provided by IIS 7.0, the other is the classic MPs queue mode, and the classic MPs queue mode is provided by the previous version of IIS.

You can set the MPs queue mode through the application pool. This function is especially useful to IIS administrators because it allows a server to run only one mode, you can also run the two modes on one server at the same time.

There are major differences between the Web. config files used in the above two pipeline modes. Many Web. config files that work normally in the classic pipeline mode cannot work normally in the integrated pipeline mode.Using appcmd.exe, We can automatically convert the configuration file format in classic pipe mode to the configuration file format in integrated pipe mode.

We need to first look at the structure of various models and study the differences between the two models.

1. Classic Mode

In the classic mode of IIS 6.0, ASP. NET is an ISAPI added to IIS.IIS 7.0 supports this mode to achieve backward compatibility. However, the classic mode lacks the features that many integration modes can provide. In Classic mode, IIS has its own pipelines. These pipelines can be expanded by creating an ISAPI extension, which is known as being difficult to develop.ASP. NET, as an ISAPI extension, is only an integral part of the IIS pipeline.

The above situation is well explained. Note: In this case, ASP. NET seems to be a result similar to the latter, and can only be used when IIS processes ISAPI extensions.
 

You can use the file extension to determine which ISAPI handler to use. For example, you can set the extension. aspx and. the ascx file is mapped to aspnet_isapi.dll, And the extension is. ASP files are mapped to ASP. DLL to process the traditional ASP page. In addition, the extension is. PHP files are mapped to PhP. DLL to process the PHP page, provided that PHP has been installed. DLL.

In addition, some features are repeated in the classic modes of IIS 6.0 and IIS 7.0. For example, error processing is a type of repeated feature, because IIS can process non-ASP. NET pages, while ASP. NET can process all pages mapped to aspnet_isapi.dll.

In IIS 6.0, we can map all file types to ASP. NET, but there are some restrictions. The maximum limit is how to deal with the default document: a default document can be processed only when it is specified as the default document in global. asax or 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.

In Classic mode, you do not need to modify the web. the current web site is running under the premise of config. Therefore, if the web farm used includes both the IIS 6.0 server and the IIS 7.0 server, or for some reason, the web. the config file is converted to a web. config file, you can use the Classic mode.

2. Integration Mode

Using the integration mode, ASP. NET can be used as an integral part of IIS.Now, the functions of the IIS server are divided into more than 40 modules, so the functions of IIS and ASP. NET are divided into different components. Modules such as staticfilemodule, basicauthenticationmodule, formsauthentication, session, profile, and rolemanager are all part of the IIS pipeline. Note: formsauthentication, session, profile, and rolemanager are originally components of ASP. NET and have no relationship with IIS.

The module explains the IIS MPs queue. These modules were originally components of ASP. NET and are now an integral part of the IIS pipeline.
 

The IIS MPs queue provides more than 20 events. developers can use these events to expand the functions of the Web server. In fact, by creating a custom module and updating applicationhost. config, you can only use custom modules, instead of using the built-in modules provided by Microsoft. We can replace the modules in IIS 7.0 with custom modules.

3. Differences between the two modes

IIS 7.0 makes some modifications to the configuration file, which can be used by web developers. For example, <system. in the webserver> section, you can identify both the classic and integrated modes. <system. webserver>, and <system. webserver> can be used in applicationhost. the config file can also be set in the web. config file. The <system. webserver> section can control both static pages and dynamic pages. Even in Classic mode, the <system. webserver> section also plays an important role. It helps web developers set different IIS configurations in the web. config file.

In integration mode, the HTTP module and HTTP handler are not defined in <system. Web>, but in <system. webserver>.If you run a web. config file that includes the HTTP module or HTTP processing program in integration mode, it will become invalid. Fortunately, Microsoft has already specified an error message numbered 500.22, which shows how to migrate the Web. config file step by step.

Configure the <system. webserver> node in IIS 7.5

Problem

Configuring the <customerror> <error> node 404 page in iis7.5 does not work.

Analysis

The <system. Web> node is the main configuration node of iis7.0 and later versions. After ii7.0, iis mps is integrated with ASP. NET MPs, which improves the processing performance of ASP. NET. Because the program runs in iis7.5 integration mode. webserver> node configuration, the newly added <system. what changes need to be made to webserver> nodes in iis7 integration mode can take effect in the following aspects:

(1) <modules> ----- equivalent to

(2)

(3) <error> ----- Under <customerror> is equivalent to

In the preceding three points, if your program contains custom httpmodules or httphandlers, the first and second points are very important. For more information, see msdn.

Configuration

<Httperrors errormode = "detailedlocalonly">
<Remove statuscode = "404"/>
<Error statuscode = "404" Path = "/404.htm" responsemode =" executeurl "/>
</Httperrors>

Supplement

Errormode has three values: custom, detailedlocalonly, and detailed, this means that the custom page is always displayed for the user and server, the detailed error information is only displayed on the server, and the detailed error information is always displayed on the user and server.

Responsemode has three layers: file, executeurl, and redirect, indicating that static files on the server, executable URLs, and URL redirection are used.

Note:

<Customerrors>

Similarly, if application_error and <customererrors> both exist, there are also execution sequence problems. Because the priority application_error event> <customerrors> configuration item, when an application-level error occurs, the code in the application_error event is preferentially executed. If the application_error event calls server. clearerror () function. defaultredirect in the <customererrors> Configuration section does not work because the exception has been cleared. If the application_error event does not call server. clearerror () function. The error page locates the URL specified by defaultredict and displays error-friendly information.

By analyzing the above four error handling mechanisms provided by. net, we can classify them from different perspectives for our understanding and use.

1. Functional Classification: handling exceptions are page_error events and application_error events. Redirecting the user to an error page) is the errorpage attribute and <customerrors> configuration item.

2. Range classification of error handling: page_error events and errorpage attributes are used for page-level error handling; application level) errors are handled by application_error events and <customerrors> configuration items.

References

Http://book.51cto.com/art/200908/146143.htm

Http://www.cnblogs.com/skyaspnet/archive/2011/03/21/1989938.html