ASP.NET intergration with IIS7

e ASP.NET Integration with IIS7 Written by Mike Volodarsky

ASP.NET Enhancements on IIS7

Better ASP.NET integration in IIS7 both enhances existing applications, and allows new applications to take advantage of ASP.NET features in new ways:

• ASP.NET services can be used for all content types.
  In the past, ASP.NET functionality such as Forms Authentication, Roles, Url Authorization, and Output Caching were only available to ASP.NET content types (ASPX pages, for example). Static files, ASP pages, and other content types could not benefit from these services.
  In IIS7, all ASP.NET services can be provided uniformly to all content. For example, you can protect all of your web content, including images and asp pages, with your existing ASP.NET 2.0 access control solution built on ASP.NET Forms Authentication, Membership and Login controls.
• Fully extend IIS with ASP.NET.
  Previous versions of IIS frequently required server extensibility to be developed using the native ISAPI filter or extension extensibility mode, due to the runtime limitations of ASP.NET.
  IIS7 allows ASP.NET modules to plug in directly into the server pipeline, with the same runtime fidelity as modules developed with the native (C++) server API. ASP.NET modules can execute in all runtime stages of the request processing pipeline, and be executed in any order with respect to native modules. The ASP.NET API has also been expanded to allow more control over request processing then was previously possible.
• Unified server runtime.
  Tighter ASP.NET integration also allows many of the features between IIS and ASP.NET to be unified. IIS7 features unified configuration for IIS and ASP.NET modules and handlers. Many other features, including custom errors, and tracing, have been unified to allow better management and cohesive application design.

ASP.NET Integration Architecture

In IIS7, the ASP.NET request processing pipeline overlays the IIS pipeline directly, essentially providing a wrapper over it instead of plugging into it.

A request arriving for any content type is processed by IIS, with both native IIS modules and ASP.NET modules being able to provide request processing in all stages. This enables services provided by ASP.NET modules like Forms Authentication or Output Cache to be used for requests to ASP pages, PHP pages, static files, and so on.

The ability to plug in directly into the server pipeline allows ASP.NET modules to replace, run before, or run after any IIS functionality. This enables, for example, a custom ASP.NET basic authentication module written to use the Membership service and SQL Server user database to replace the built in IIS basic authentication feature that works only with Windows accounts.

In addition, the expanded ASP.NET APIs take advantage of direct integration to enable more request processing tasks. For example, ASP.NET modules can modify request headers before other components process the request, inserting an Accept-Language header before ASP applications execute in order to force localized content to be sent back to the client based on user preference.

Because of the runtime integration, IIS and ASP.NET can use the same configuration for enabling and ordering server modules, and configuring handler mappings. Other unified functionality includes tracing, custom errors, and output caching.

Runtime Fidelity

In Integrated mode, the ASP.NET request processing stages exposed to modules are directly connected to the corresponding stages of the IIS pipeline. The complete pipeline contains the following stages, exposed as HttpApplication events in ASP.NET:

1. BeginRequest. The request processing is starting.
2. AuthenticateRequest. The request is being authenticated. IIS and ASP.NET authentication modules subscribe to this stage to perform authentication.
3. PostAuthenticateRequest
4. AuthorizeRequest. The request is being authorized. IIS and ASP.NET authorization modules check whether the authenticated user has access to the resource being requested.
5. PostAuthorizeRequest
6. ResolveRequestCache. Cache modules can check whether the response to this request exists in the cache, and return it instead of proceeding with the rest of the execution path. Both ASP.NET Output Cache and the new IIS Output Cache features execute here.
7. PostResolveRequestCache
8. MapRequestHandler. This stage is internal in ASP.NET, and is used to determine the request handler.
9. PostMapRequestHandler
10. AcquireRequestState. The state necessary for the request execution is being fetched. ASP.NET Session State, and Profile modules obtain their data here.
11. PostAcquireRequestState
12. PreExecuteRequestHandler. Any tasks before the execution of the handler can be performed here.
13. ExecuteRequestHandler. The request handler executes here. ASPX pages, ASP pages, CGI programs, and static files are served here.
14. PostExecuteRequestHandler
15. ReleaseRequestState. The request state changes are saved, and the state is cleaned up here. ASP.NET Session State and Profile modules use this stage for cleanup.
16. PostReleaseRequestState
17. UpdateRequestCache. The response can be stored in the cache for future use here. The ASP.NET Output Cache and IIS Output Cache modules execute here to save the response to their caches.
18. PostUpdateRequestCache
19. LogRequest. This stage is used to log the results of the request, and is guaranteed to execute even if errors occur.
20. PostLogRequest
21. EndRequest. This stage is used to perform any final request cleanup, and is guaranteed to execute even if errors occur.

The ability to execute in the same stages as IIS modules makes many tasks previously only accessible to native ISAPI filters and extensions now possible in managed code, using the familiar ASP.NET APIs and the rich functionality of the .NET platform. For example, you can now write modules that do the following:

• Intercept the request before any processing has taken place, for example for re-writing urls or performing security filtering.
• Replace built in authentication modes.
• Modify the incoming request contents, such as request headers.
• Filter outgoing responses for all content types.