IIS 7.0 : Hosting Application Development Frameworks - Hosting ASP Applications & Hosting PHP Applications

Hosting ASP Applications

IIS 7.0 continues to fully support ASP applications, but it does not introduce any significant improvements or changes to the ASP support as it does for ASP.NET. Nonetheless, ASP applications benefit from the improved configurability and new Web server features provided by IIS 7.0. In addition, the ASP.NET integrated pipeline provides the capability to use valuable ASP.NET features for ASP applications, offering a short-term functionality enhancement path that does not require a complete rewrite to ASP.NET.

Note

For Web applications, ASP.NET unlocks a much richer set of Web server functionality, enables rapid development with Microsoft Visual Studio tool support, and provides greater interoperability with the features of the .NET Framework and the Windows platform.

In the next few sections of this chapter, we will discuss the steps necessary to install ASP and deploy ASP applications on IIS 7.0.

Installing ASP

Due to the modular nature of IIS 7.0, ASP support is a stand-alone component that needs to be installed before ASP applications will run on the server. ASP can be installed using Programs And Features in Windows Vista or as a role service, using Server Manager in Windows Server 2008. 

Installing ASP also installs the ISAPI extension support, because ASP is implemented as the ASP.dll ISAPI extension. It also automatically enables the ASP.dll ISAPI extension in the system.webServer/security/isapiCgiRestriction configuration section to allow the extension to execute on the server. After the ASP component is installed, your ASP applications should begin working.

Deploying ASP Applications

The way that ASP applications work on IIS has not changed in IIS 7.0. As a result, ASP applications should just work. You do not need to manually create handler mappings for ASP, because Windows Setup does this for you at the server level when the ASP support is installed. It also adds the ASP.dll ISAPI extension to the system.webServer/security/isapiCgiRestriction configuration section to enable it to run. Therefore, it is not necessary to complete this task manually as in IIS 6.0 (where you had to enable it in the Web Service Extension Restriction List). To deploy an ASP application, you simply need to perform the following steps:

1. Create an IIS application.

2. Deploy the contents of the ASP application.

Much like ASP.NET applications, ASP applications must be placed inside an IIS application. This requirement isn’t new in IIS 7.0. However, IIS 7.0 does provide a much firmer definition of an application than previous versions of IIS do. Therefore, you need to make sure that the ASP application is deployed into the root virtual directory of an IIS application, and you may be required to create this application. You can do this from the IIS Manager, or by using Appcmd as follows.

%systemroot%\system32\inetsrv\appcmd.exe add app "/site.name:SiteName"
"/path:VirtualPathOfApplication"
"/physicalPath:PhysicalPathOfApplication"

You can also deploy individual ASP pages to any existing application or virtual directory on your server, in which case they will become part of the corresponding application. However, if your ASP application contains application-level functionality such as the Global.asa file, you will need to make sure that the application contents are deployed to the root of an IIS application. In some cases, you will want to create a separate application to isolate your application functionality from other applications—for example, if your ASP pages store state in the ASP Application object.

Note

The .NET Framework version and the ASP.NET integration mode of the application pool hosting the ASP application have no effect on the ASP application. Because of this, ASP applications can work in any of the application pools regardless of those settings. However, for ASP applications to take advantage of services provided by managed modules, they must be in application pools that support ASP.NET Integrated mode.

Finally, you may want to take advantage of creating a separate application to isolate your application by placing it in a separate application pool. This can provide additional stability by creating a process boundary between your ASP application and other applications on the server, and doing so also allows you to set permissions on the application content so that only your application pool can gain access to it.

Additional Deployment Considerations

This section describes additional deployment considerations for hosting ASP applications on IIS 7.0.

Enabling Script Errors to Be Shown

IIS 7.0 disables the sending of script errors to the browser by default for security reasons. You can enable this behavior by setting the scriptErrorSentToBrowser configuration attribute in the system.webServer/asp configuration section. You can use Appcmd.exe to do this as follows.

%systemroot%\system32\inetsrv\Appcmd set config ConfigurationPath
/section:system.WebServer/asp /scriptErrorSentToBrowser:true

ConfigurationPath is the optional configuration path to set this setting for. The default is the entire server if the configuration path is omitted.

In addition, you may need to configure the IIS 7.0 custom errors feature to allow detailed errors to be sent to the browser. By default, IIS 7.0 will only send detailed error responses when the request is made from the local server, and it will send a generic error message to remote clients. 

Parent Paths Disabled by Default

Starting with IIS 6.0, the ability to use parent path ("..") segments in calls to ASP functions such as the Server.MapPath has been disabled to prohibit opening of files outside of the application root. This may cause issues for some applications that use parent paths with this function to calculate file paths or use them in #include directives.

If your application encounters this condition, you may receive error messages such as "The Include file ‘file’ cannot contain ‘..’ to indicate the parent directory" or "The ‘..’ characters are not allowed in the Path parameter for the MapPath method". When faced with an error such as one of these, you can modify the application to not use parent paths, or if you are sure that the use of parent paths does not create a vulnerability, you can enable parent paths by setting the enableParentPaths configuration attribute in the system.webServer/asp configuration section. You can use Appcmd.exe to do this as follows.

%systemroot%\system32\inetsrv\Appcmd set config ConfigurationPath
/section:system.WebServer/asp /enableParentPaths:true

As before, ConfigurationPath is the optional configuration path to set this setting for. The default is the entire server if the configuration path is omitted.

Hosting ASP Applications on Remote UNC Shares

ASP applications, like all ISAPI extensions by default, always impersonate the authenticated user when executing scripts and accessing resources. For applications that enable anonymous access, the authenticated user will be the built-in IUSR account by default. You can also configure anonymous authentication to use the application pool identity instead of a separate account.

When the application is hosted on a UNC share, the default anonymous user (IUSR) and the default application pool identity (Network Service) do not have the rights to access the remote network share. Because of this, you will need to make sure that the application pool and the authenticated user have the right to access the network share. This is typically done using one of the following options:

• Configure fixed credentials for the application’s virtual directories located on a UNC share, which have access to the remote share. The ASP application will then always impersonate these credentials instead of the authenticated user.

• Configure a custom application pool identity that has access to the share. If using anonymous authentication, configure it to use the application pool identity. If using other authentication methods, make sure that all authenticated users have access to the network share.

Hosting PHP Applications

IIS 7.0 provides built-in support for the FastCGI protocol, which is a more efficient and reliable mechanism for hosting PHP applications than CGI or ISAPI, the other two modes supported by PHP. The FastCGI protocol eliminates the high per-request process creation overhead associated with the CGI protocol on Windows by pooling processes and reusing them to process requests. By ensuring that only a single request is processed by each FastCGI process at a time, it maintains the required single-threaded environment needed by non–thread-safe application frameworks.

Direct from the Source: The History of PHP Support in IIS

IIS has long supported the PHP application framework. In fact, the standard PHP distributions provided two mechanisms for interfacing with IIS: a CGI-compliant executable, and an ISAPI extension. However, both of these modes have certain limitations that often preclude production-quality hosting of PHP applications on IIS 7.0.

The CGI mode often experiences very low performance, because a new PHP CGI process has to be started to handle each request. This dramatically reduces performance due to the high process creation overhead on the Windows platform. The ISAPI mode does not suffer from a performance problem, because ISAPI is a multithreaded in-process component that does not start new processes and is therefore capable of very high performance. However, historically the PHP scripting engine and most of the commonly used PHP extensions were not developed to be thread-safe, often resulting in instability and crashes when used in the multithreaded ISAPI environment. Even after the PHP scripting engine itself became thread-safe, many commonly used open source extensions remain non–thread-safe, keeping many PHP applications from being stable when hosted in ISAPI mode.

With IIS 7.0, we have taken a hard look at what it means for IIS to be an excellent application platform. We realized that this means supporting a wide variety of application frameworks and making sure that these frameworks not only work reliably on IIS but also can leverage the powerful IIS 7.0 and Integrated ASP.NET features. We saw that the PHP problems were common among other open source application frameworks, and so the FastCGI project was born. I—along with Bill Staples, IIS product unit manager—first announced this project in September 2006 as an integral part of our collaboration with Zend, the creator of PHP, to bring rock-solid PHP support to the IIS platform. 

Since then, FastCGI support has been added to Windows Server 2008 and has been made available for IIS 6.0 as a download. This support is quickly opening doors for production hosting of PHP applications on IIS. We are also working with other application framework communities to make sure that they are able to successfully leverage the FastCGI environment, and we are hoping to see more and more application frameworks leveraging FastCGI to work better on IIS.

Mike Volodarsky

IIS Core Server Program Manager

In the remainder of this section, we will review the steps necessary to enable PHP applications to work on IIS 7.0.

Deploying PHP Applications

To enable PHP support, you will first need to install FastCGI on the server. Second, you will need to download and install the PHP framework itself.

Installing FastCGI

Before you can run PHP in FastCGI mode, you need to install FastCGI on the server.

FastCGI support is part of Windows Vista SP1 and Windows Server 2008. FastCGI can be installed as part of the CGI component using Programs And Features in Windows Vista or as a role service, or using Server Manager in Windows Server 2008.

Note

FastCGI support was not part of IIS 7.0 in Windows Vista, but it is included in SP1. You will need to install SP1 to obtain FastCGI on Windows Vista. It is included by default in Windows Server 2008.

After the CGI component is installed, FastCGI support is available on the Web server. The FastCGI module is actually a separate module from the CGI module, but both are installed as part of the CGI setup component (the reasons for this are historical). Installing FastCGI and CGI support does not automatically enable any CGI or FastCGI programs to execute on your server. You will need to manually enable the PHP FastCGI executable to allow them to run.

Installing PHP

You can download builds of the PHP framework from http://www.php.net/downloads. You can also download the PHP Extension Community Library (PECL) from the same site. In doing so, you will have two options:

• Download the standard Win32 binaries.

• Download the non–thread-safe Win32 binaries

Note

You also have the option to download an MSI-based installer. However, this installer has been shown to generate conflicting configurations, and therefore, it is not recommended.

The non–thread-safe binaries are optimized for the FastCGI execution environment, which does not require thread safety due to the single request per process execution model. These binaries, therefore, gain a significant performance boost due to removing the overhead of thread safety and are recommended for the IIS 7.0 FastCGI environment.

Caution

Use the standard thread-safe libraries if you are planning to use PHP in the ISAPI environment. However, doing so may still lead to instability and is not recommended, because not all PHP extensions are thread safe. Use FastCGI with the non–thread-safe PHP binaries for optimal performance and stability.

After downloading the PHP binaries, you can simply unzip them to a directory on your machine and follow the standard installation procedures for PHP, which sometimes involve renaming the php.ini-recommended configuration file in the PHP directory to Php.ini and making specific modifications to it to allow your PHP applications to run. You may at minimum need to set the PHP .INI settings listed in Table 1.

Table 1. PHP .INI Settings for IIS 7.0 FastCGI

PHP .INI Setting	Explanation
cgi.fix_pathinfo=1	This ensures the correct values for the PATH_INFO/PATH_TRANSLATED CGI server variables. PHP’s previous behavior was to set PATH_TRANSLATED to SCRIPT_FILENAME and ignore PATH_INFO. Using this setting causes PHP to fix path-related variables to conform to the CGI specification.
fastcgi.impersonate = 1	This setting enables PHP to impersonate the authenticated user. You may want to set this setting.

You may also need to set additional settings that are specific to the PHP application you are using, for example to load a required PHP extension library. In addition, you may want to set some FastCGI settings to tune performance to the needs of your PHP application. 

Finally, to allow PHP to be used from IIS, you have to make sure that IIS has Read access to the directory containing the PHP framework files and the application content. By default, IIS application pools run as Network Service and therefore are members of the Users group, which does have Read access to most directories on the server. However, if Network Service does not have access, or you are using a custom application pool identity, you can grant Read and Execute access to the IIS_IUSRS group to grant IIS access to the PHP framework files.

Deploying PHP Applications

To allow PHP applications to run using FastCGI, you need to do the following:

1. Create a FastCGI application entry for each PHP version.

2. Create a FastCGI handler mapping for *.php scripts to be processed with PHP’s FastCGI -compliant executable.

Because IIS Manager will automatically perform step 1 when you create the corresponding handler mapping, we will discuss creating the handler mapping in IIS Manager as a way to perform both tasks in one step.

Creating a FastCGI Handler Mapping for PHP

After the FastCGI support and the PHP framework are installed on the server, you can enable PHP scripts to be executed using FastCGI. Do this by creating an IIS handler mapping that uses the FastCGI module to process requests to PHP scripts by using the PHP FastCGI executable. This mapping can be added globally on the server to enable PHP scripts to run on all Web sites on the server, or it can be added for a specific site or URL to enable PHP scripts to run there.

The quickest way to create this handler mapping is with IIS Manager. First, select the server node or the site node in the tree view depending on the desired scope for the handler mapping. Then double-click Handler Mappings. 

You can create the handler mapping for PHP by using the Add Module Mapping action, specifying the FastCGIModule in the Module drop-down list, and specifying the path to the PHP-CGI.EXE executable in your PHP installation directory, as shown in Figure 1.

Figure 1. Adding a FastCGI handler mapping for PHP in IIS Manager.

When you press OK to create the mapping, you will see a dialog box asking to create the FastCGI application entry for the Php-cgi.exe executable, as shown in Figure 2. This is required to run Php-cgi.exe with FastCGI (this is similar to adding a CGI executable to the Web Extension Restriction List on IIS 6.0).

Figure 2. Add Module Mapping confirmation dialog box.

Clicking OK in this dialog box allows you to quickly create the required FastCGI application configuration without having to configure it manually. This dialog box is shown only the first time a specific path to the Php-cgi.exe executable is encountered to create a global FastCGI application entry for that executable. This means that you will see it only once for each version of PHP you use in handler mappings on the server. Because a separate FastCGI application entry is created for each unique executable, this allows you to host PHP applications on your server using more than one version of the PHP framework. To use multiple versions side by side, simply create the separate PHP handler mappings by using the appropriate version of the Php-cgi.exe executable for different sites on the server. IIS Manager will prompt you to create a FastCGI application entry once for each version.

The FastCGI application entry defines additional settings including the number of requests that a single instance of the Php-cgi.exe process will execute and how many of these processes are allowed to be created at the same time. 

Additional Deployment Considerations

When PHP is running in the FastCGI environment, you may want to take into account a few additional deployment considerations. These include the following:

• Deciding on the execution identity for PHP scripts

• Ensuring availability of PHP applications by adjusting concurrency and process lifetime

These considerations are strongly related to the FastCGI process model, which impacts how PHP processes are created and used to process PHP requests when in FastCGI mode. 

Configuring PHP Execution Identity

By default, PHP scripts will be executed under the process identity of the Php-cgi.exe worker process. Unlike CGI, which starts a new process to handle each request and executes this process with the identity of the IIS authenticated user by default, FastCGI worker processes are long-lived and always execute under the same identity as the parent application pool. This means that PHP scripts will be executed with the identity of the application pool to which the IIS application that contains the scripts belongs. This aligns well with the IIS model, enabling you to manage access to resources in a uniform way across the entire site. It also enables you to securely isolate PHP applications in the same manner as the rest of the site contents by using application pool isolation. 

Note

Unlike CGI, FastCGI application processes, including PHP’s Php-cgi.exe, always execute with the identity of the application pool to which the PHP application belongs.

However, some PHP applications rely on executing PHP scripts under the identity of the authenticated user. This is often done as a way to use the IIS authenticated user to authorize access to other resources the application uses and to isolate users from one another. In fact, PHP applications that run using the CGI or the ISAPI mode impersonate the authenticated user by default. Historically, impersonation has been especially important to lower the execution privilege of PHP scripts because the parent IIS process may have been executing as the LocalSystem account (in IIS 5.0 and previous versions). This latter requirement is no longer there in IIS 7.0 because IIS application pools are by default configured to run with the lower privilege of the Network Service account.

To enable PHP scripts to execute with the identity of the authenticated user, you can configure PHP to impersonate the authenticated user when hosted in the FastCGI environment. Though the Php-cgi.exe process will still execute under the parent application pool identity, the PHP engine will impersonate the authenticated user when executing the PHP script. This is done by setting the fcgi.impersonate setting in the PHP’s Php.ini configuration file to 1.

; FastCGI under IIS (on WINNT based OS) supports the ability to impersonate
; security tokens of the calling client. This allows IIS to define the
; security context that the request runs under.
; Set to 1 if running under IIS. Default is zero.
fastcgi.impersonate = 1

Note

Impersonation takes effect only when an authenticated user is available and represents a valid Windows principal. Non-Windows authentication schemes such as Forms authentication do not support impersonation.

When using impersonation and anonymous authentication, PHP scripts will execute with the IUSR identity by default (the anonymous user in IIS 7.0). You can change the anonymous user identity in the system.webServer/security/authentication/anonymousAuthentication configuration section as well as make the anonymous user be the identity of the worker process. 

Note

IIS 7.0 FastCGI provides support for impersonation of the authenticated user. However, at the time of this writing, only the PHP framework is known to support this. Other frameworks using FastCGI will execute under the identity of the parent application pool.

Hosting PHP Applications on Remote UNC Shares

When running PHP applications on remote UNC shares, you need to ensure that the Php-cgi.exe process has access to the application content on the UNC share. Due to the two mechanisms for running PHP discussed earlier in this chapter, there are two options for configuring this:

• If using impersonation, configure the fixed credentials for the virtual directory hosting the PHP application content on a remote UNC share. PHP will then impersonate these credentials when accessing the content and executing scripts. This option is recommended.

• If not using impersonation, make sure that the application pool identity has access to the UNC share.

Ensuring Availability of PHP Applications

The FastCGI hosting mode provides several settings that can be adjusted in order to tune the performance and availability of PHP applications. These settings are available on the FastCGI application entry for each unique version of Php-cgi.exe in use on the system, which are located in the global system.webServer/fastCgi configuration section.

These settings may need to be used to ensure the availability of PHP applications by tuning the FastCGI pool behavior. In particular, the instanceMaxRequests setting for the PHP FastCGI application, which controls the number of requests processed by each Php-cgi.exe process before it is shut down, must be set to a number under the PHP request limit. This limit is 500 by default, and you can override it by specifying the PHP_FCGI_MAX_REQUESTS environment variable in the FastCGI application configuration . The default instanceMaxRequests value is 200, which is under the PHP’s default, but it is recommended to set both to 10,000 to achieve optimal performance.