MSDN Magazine Launch Issue - February 15, 2008 - (Page 46) The response filtering work is done inside the ChainedBufferedStringResponseFilter class, which is responsible for converting the response bytes into a string using the response character set, and invoking one or more response filters that apply to this request. The module associates the filter with the response by setting the HttpResponse.Filter property. This property accepts objects that inherit from the System.IO.Stream abstract class and later uses them to filter the outgoing response entity body. The ASP.NET response filtering facility is just one of the mechanisms that you can take advantage of when develThe new configuration oping ASP.NET modules system is the foundation for for IIS 7.0 Integrated mode. You can also rewrite URLs, many of the key deployment perform request authentiand management scenarios cation and authorization, possible with IIS 7.0. modify or issue cookies and response headers, log the request, and so on. Most of the tasks that previously required native ISAPI development are now possible by simply writing an ASP.NET module. You can find a step-by-step walkthrough of building ASP.NET modules for IIS 7.0, the development environment options, and deployment steps at mvolo.com/blogs/serverside/archive/ 2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx. When developing an IIS 7.0 module, you can take advantage of a number of IIS features that aid in management and deployment. One of these features is the ability to specify custom module configuration in the IIS 7.0 configuration files, and either have that configuration deployed automatically with the application, or managed with a number of IIS 7.0 administration tools and APIs. Doing this is key to ensuring that the functionality provided by the module can be properly configured and managed by end users. Extending Configuration the ASP.NET configuration system. Moreover, the syntax of the IIS configuration information is identical to that of the ASP.NET configuration information and can be placed side-by-side in distributed web.config files that ASP.NET developers are already very familiar with and love. This design opens many doors. First, it allows applications to specify IIS configuration information alongside their application content, which makes them easy to deploy by simply publishing their content to the server. This ensures that the applications work correctly without needing to modify machine-centric configuration information on each server on which they are deployed and also without requiring Administrative privileges on each server. The structured XML configuration format, plus the ability to put ASP.NET configuration together with IIS configuration in a single file, makes it a lot easier for developers to author and manage all IIS-related configuration information. This can be done with an XML editor such as Notepad and Visual Studio® or can be automated by using the configuration APIs provided by the IIS 7.0 administration stack. The best part about all of this is the fact that the IIS 7.0 configuration system is completely extensible. Allowing custom Web server features to publish configuration that can be set and managed sideby-side with the IIS 7.0 configuration plays a key role in building complete solutions for IIS 7.0. Unlike the .NET configuration system, adding a new IIS 7.0 configuration section requires no code because all IIS 7.0 configuration sections are themselves defined using an XML-based schema. In fact, all built-in IIS 7.0 configuration sections are defined using this mechanism. You can find the definitions for all IIS configuration sections in the %windir%\system32\inetsrv\config\schema directory in the IIS_Schema.xml file. For example, the configuration section, which enables and configures default documents for your application, is defined as follows: The new configuration system is the foundation for many of the key deployment and management scenarios possible with IIS 7.0. Instead of being a proprietary machine-central configuration store, the IIS 7.0 configuration system is based on structured XML configuration files located in the same configuration files used by Figure 3 Response Modification Configuration Schema This schema defines all of the elements and attributes that are part of the configuration section, their types, and additional information such as collection definitions, and attribute validation behavior. To learn more about the syntax of the schema definition, see the comments at the top of the IIS_Schema.xml configuration file. The Response Modification module requires its own configuration section in order to configure a number of specific settings, including what filtering rules to enable for the application. To allow this configuration section to be used in the IIS configuration files, you first need to create the schema file describing the structure of the section (see Figure 3). This file defines the responseModification section and its structure, including the enabled attribute and the collection of filter rules that can be configured to invoke filter Response Modification Configuration 46 msdnmagazine IIS 7.0 http://mvolo.com/blogs/serverside/archive/2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx http://mvolo.com/blogs/serverside/archive/2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx
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.