IIS 7.0 : Techniques for Enabling Application Frameworks (part 1) - Enabling New Static File Extensions to Be Served & Deploying Frameworks Based on IIS 7.0 Native Modules

IIS 7.0 provides several options for hosting third-party application frameworks, depending on how the application framework’s developer chooses to interface it with IIS. The options include:

• IIS 7.0 native module. Application frameworks that integrate with IIS by using the IIS 7.0 native module APIs to handle requests

• ASP.NET handler. Application frameworks that integrate with IIS by using the ASP.NET handler APIs

• ISAPI extension. Application frameworks that integrate with IIS by using the legacy ISAPI extension APIs

• FastCGI application. Application frameworks that provide executables that support the open FastCGI protocol to integrate with IIS

• CGI application. Application frameworks that provide executables that support the open CGI protocol to integrate with IIS

To enable application frameworks by using any of the preceding options to work on IIS 7.0, the basic requirement is to create a handler mapping that maps requests to specific extensions to the application framework’s handler component. This component may be using any one of the options listed earlier to interface with IIS. 

You can create the handler mapping at the server level or for a specific Web site, application, virtual directory, or URL. Doing so will allow requests made to the level where the mapping is created to be forwarded to the application framework for processing.

Note

This section reviews general techniques for integrating application frameworks with IIS 7.0. You will need to review the documentation provided with each framework for instructions that may contain framework-specific configuration steps.

For all of these options, you can use IIS modules to provide additional request processing services. This includes using any of the IIS authentication mechanisms, authorization, output caching, response compression, and logging. Furthermore, for applications running in Integrated mode, you can also leverage services provided by managed (ASP.NET) modules in the same manner for all requests regardless of the application framework. 

The remainder of this section will discuss the specifics of each application framework integration option in detail, including using the new FastCGI module to host FastCGI-compliant application frameworks such as PHP.

Enabling New Static File Extensions to Be Served

IIS 7.0 supports basic file server functionality in the default install, provided by StaticFileModule. This module is by default configured to handle all requests that are not otherwise handled by other handlers. This means that any request to a resource that does not match a handler mapping will be handled by the Static File module.

StaticFileModule will serve only resources whose extensions are configured to be served. This is very important, because otherwise all unknown resources in the application’s servable namespace, including data files or application scripts, may end up served as static files.

The list of allowed static files is located in the system.webServer/staticContent configuration section. This is the equivalent of the IIS 6.0 MIME Type configuration. In IIS 7.0, the default list of allowed static files has been expanded to contain modern file types including file types used by Shockwave, Microsoft Silverlight, and Microsoft Office 2007. You can configure the list of static files at any configuration level, which allows specific applications to add or remove custom file types without affecting the entire server.

If your application contains a file type that should be served as a static file but is not currently registered in this section, you will need to add its extension and the associated MIME content type information before it can be served.

You can use IIS Manager to do this by expanding the IIS computer node in the Connections pane, navigating to the Sites node, and selecting the level at which you’d like to configure MIME types. (You can manage MIME type configuration at the site, directory, and virtual directory level.) Double-click the MIME Types feature to display the MIME Types page, as shown on Figure 1.

Figure 1. Configuring MIME types using IIS Manager.

You can also configure MIME types by using Appcmd. To add a MIME Type entry, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config
/section:system.WebServer/staticContent "ConfigurationPath"
"/+[fileExtension='string',mimeType='string']"

To delete a MIME Type entry, to prevent the associated extension from being served as a static file, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config
/section:system.WebServer/staticContent "ConfigurationPath"
"/-[fileExtension='string']"

The parameters to these commands are described in Table 1.

Table 1. Parameters for Adding MIME Types

Parameter	Description
ConfigurationPath	The configuration path at which to apply this configuration.
fileExtension	The file extension to add or delete.
mimeType	The MIME type of the file extension. This will be sent as the content-type header of the response when sending the contents of the associated resources to the client.

The MIME Type configuration applies only if the file extension is not already mapped to another handler in the IIS 7.0 handler mapping configuration.

Caution

Do not add MIME Type entries for resources that are not meant to be served as static files, such as application script files or data files. If the frameworks that typically handle these resources are removed, the Web server may accidentally serve these files as if their MIME Types are registered in the static content configuration.

Deploying Frameworks Based on IIS 7.0 Native Modules

The IIS 7.0 native module is the preferred way to integrate application frameworks with IIS 7.0 and future versions of IIS, because it provides the maximum performance and functionality to the application framework. It is also significantly easier to develop against and more powerful than ISAPI extension API available in previous versions of IIS. However, because this is the newest API, introduced in IIS 7.0, it is also the least commonly used today (this will change as developers adopt IIS 7.0). Adding application frameworks based on IIS 7.0 native modules requires administrative privileges on the server.

To deploy an application framework that uses this mechanism, you need to do the following:

1. Install the native module on the server. This requires administrative privileges.

2. Enable the native module on the server (typically done by default when the module is installed) or for a specific application where it is used.

3. Create a module-based handler mapping entry that maps the desired URL paths to the module. Do this at the server level or for a specific site, application, or URL.

4. Optionally, install the corresponding configuration schema and UI extensions for configuring your module. Then set the module-specific configuration. 

Because IIS 7.0 modules are loaded In-Process by the IIS worker process, the application framework will by default execute under the identity of the parent IIS application pool (unless the framework specifically implements the ability to impersonate authenticated users or arbitrary credentials, like ASP.NET does). This means that you must set permissions on the application framework files to allow them to be read by the IIS worker process. You do this by granting Read access to the IIS_IUSRS group.

Additionally, if you need to isolate your applications for reliability or security reasons, you need to use the IIS application as a unit of isolation by placing different applications in different IIS application pools.