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
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.
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
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
To delete a MIME Type entry, to prevent the
associated extension from being served as a static file, you can use the
%systemroot%\system32\inetsrv\Appcmd set config
The parameters to these commands are described in Table 1.
Table 1. Parameters for Adding MIME Types
The configuration path at which to apply this configuration.
The file extension to add or delete.
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.
MIME Type configuration applies only if the file extension is not
already mapped to another handler in the IIS 7.0 handler mapping
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
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
To deploy an application framework that uses this mechanism, you need to do the following:
Install the native module on the server. This requires administrative privileges.
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.
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.
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.