MSDN Magazine Launch Issue - February 15, 2008 - (Page 45) built on public extensibility APIs, you can replace any of them with a custom implementation that best fits your needs. IIS 7.0 provides two options for developing Web server modules. First, you can use the new C++ module API on which most of the built-in features are based. The module API replaces the ISAPI extension and filter API offered in previous versions of IIS. This API is a significant improvement over ISAPI, as it is rich enough to support all of the IIS 7.0 features and it is significantly easier to program against. You can learn more about the improvements in this API at mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-whyserver-development-is-better-with-IIS7.aspx. Second, IIS 7.0 features ASP.NET integration, which allows IIS 7.0 modules to be developed by using the familiar ASP.NET module APIs. With ASP.NET Integrated mode, these modules become first-class citizens in the IIS request processing pipeline, as shown in Figure 1. This enables ASP.NET modules to access IIS intrinsic objects, such as the request and response, in all stages of request processing, and to process requests for all resource types—not just those handled by the ASP.NET framework. This allows powerful ASP.NET features like Forms-based authentication, Login controls, and the Membership service, to be used uniformly for the entire Web site. For an in-depth view of how ASP.NET Integrated mode can be used to add value to existing applications not written for the ASP.NET framework, be sure to read my article in the January 2008 issue of MSDN® Magazine at msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7. For developers, the real value of the ASP.NET Integrated mode is the ability to extend the IIS Web server using the Microsoft® .NET Framework. This brings significant benefits in rapid application development by providing the ability to build on the rich framework support of the .NET Framework, ASP.NET, and other frameworks like the Windows Workflow Foundation. Figure 1 ASP.NET Modules in IIS 7.0 Request Processing class ResponseModificationModule : IHttpModule { public void Init(HttpApplication app) { // Wire up the filter in PreRequestHandlerExecute app.PreRequestHandlerExecute += new EventHandler(OnPreRequestHandlerExecute); } public void OnPreRequestHandlerExecute( Object source, EventArgs e) { } } A Response Modification Module The ASP.NET Integrated pipeline enables ASP.NET modules to perform a wide variety of tasks during the processing of each request. This wide variety ranges from performing authentication or authorization to modifying the outgoing response before it is sent to the client. The purpose of the Response Modification module is to do the latter, to allow existing responses to be modified on the fly using a set of replacement rules. To do this, we can leverage the ASP.NET response filtering mechanism, which, thanks to the runtime integration, allows filtering of the outgoing responses for any content, including static files and ASP and PHP scripts. If you have developed an ASP.NET module in the past, you’ll appreciate the fact that you continue to use the same exact APIs to develop ASP.NET modules for IIS 7.0. In fact, your existing modules continue to work the same way as they did in previous versions of IIS (unless you take advantage of IIS 7.0 Integrated mode to run them for all requests). The module is a class that implements the System.Web.IHttpModule interface and registers event handlers for one or more request pipeline events. The Response Modification module is no different: At its core, the module subscribes to the PreRequestHandlerExecute event, which occurs right before the request handler is executed. The OnPreRequestHandlerExecute method is used to read configuration information to determine whether the response has any applicable replacement rules (more on configuration later in the article), and if so, register a response filter stream that will later be used to filter the outgoing response, as shown in Figure 2. Figure 2 Response Filter public void OnPreRequestHandlerExecute(Object source, EventArgs e) { HttpApplication app = (HttpApplication)source; HttpContext context = app.Context; // Read configuration ResponseModificationConfigurationSection config; // Get the list of filters ResponseFilterList filters = GetApplicableFilters(context, config); // Create the filter and wire it up if (null != filters && filters.Count > 0) { context.Response.Filter = new ChainedBufferedStringResponseFilter( context, filters); } } launch2008 45 http://mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx http://mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx http://msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.