RuslanY Blog

Major revision of FastCGI/PHP article on IIS.NET

Since the time we have published the article about installing FastCGI and PHP on IIS 7.0 it has become one of the most popular articles on http://learn.iis.net. Also it has received a lot of comments from site visitors. Today, we are publishing the updated version of this article that contains more up-to-date information and addresses most of the feedback from community. Here is what this article includes now:

Please take a look at the new content and leave comments if you have any questions of feedback.

Acknowledgments: I would like to thank IIS.NET visitors who have provided their comments and corrections to this article. Also I thank Jake and Bill for doing a final review of the article.

ASP.NET postbacks and URL rewriting

ASP.NET Web Forms extensively use postback mechanism in order to maintain the state of the server-side controls on the web page. This makes it somewhat tricky to perform URL rewriting for ASP.NET pages. When a server side form control is added to the web page, ASP.NET will render the response with HTML <form> tag that contains an action attribute pointing back to the page where the form control is. This means that if URL rewriting was used for that page, the action attribute will point back to the rewritten URL, not to the URL that was requested from the browser. This will cause the browser to show rewritten URL any time a postback occurs.

Let me demonstrate this on an example. Assume you have a very simple web form in a file called default.aspx. When you request http://localhost/default.aspx in a browser and then view the HTML source for the response, you will see that the response contains the <form> element, which looks similar to this:

Wildcard script mapping and IIS 7 integrated pipeline

The big benefit of IIS 7 integrated request processing pipeline is the fact that all the nice and useful ASP.NET features can be used for any type of content on your web site; not just for ASP.NET-specific content. For example, ASP.NET SQL-based membership can be used to protect static files and folders. Also, ASP.NET extensibility API’s, such as IHttpHandler and IHttpModule can be used to add custom modules and handlers that would be executed even for non-ASP.NET content.

IIS 6 did not have this level of integration. ASP.NET was plugged into IIS 6 as an ISAPI extension and by default was configured to handle ONLY requests mapped to that extension – for example any request that ended with “.aspx” would be be processed by ASP.NET extension. This obviously was a big limitation for customers who wanted to be able to use ASP.NET features for all other contend on web site. The most common way to workaround that was to use “Wildcard script mapping”. This post explains how an application that used wildcard script mapping in IIS 6 can be migrated over to IIS 7.

Assume you had configured ASP.NET in IIS 6 to handle all requests by using wildcard script mapping. For example you had an ASP.NET module for URL rewriting and you wanted this module to handle extension-less URLs.

Video walkthrough for URL Rewrite Module

Last week I have recorded a video screencast that shows how to use URL Rewrite Module for IIS 7.0 to perform some common URL manipulations tasks. Today this video has been published on IIS.NET – check it out at this location.

The video demonstrates how to create rewrite rules to perform the following tasks:

Enabling user friendly and search engine friendly URLs for dynamic web pages;
Enforcing canonical host names, so that site visitors as well as search engines always use a particular domain name for your web site;
Using rewrite maps to define static mappings between requested and rewritten URLs;
Blocking unwanted site crawlers by aborting requests based on HTTP user-agent header.

In addition, the video shows how to test, troubleshoot and debug rewrite rules by using “Test pattern” tool and IIS 7.0 Failed Request Tracing.

Please take a look and leave comments or questions if anything is not clear or you would like to get more information on a particular topic.

URL Rewrite Module – Go Live release

Today IIS team has made the Go Live release of URL Rewrite Module for IIS 7.0 available for download. This release contains significant functionality and performance improvements and it is believed to have a quality level suitable for production deployments.

Download the Go Live release of the module today!

Note that the installer for URL Rewrite Module includes the FastCGI update for IIS 7.0. If this update has not been yet installed on your machine it will be installed together with URL Rewrite Module.

ASP.NET Routing, Request Filtering, URL Rewriting

Today I have published two new articles on http://learn.iis.net. The articles are intended to explain the differences between various URL manipulation technologies available in IIS 7.0 and to provide help with choosing of the technology best suited for a particular usage scenario.

Here is the short summary of the articles:

IIS 7.0 URL Rewriting and ASP.NET Routing – with the release of URL-rewrite module for IIS 7.0 and the inclusion of ASP.NET routing into the .NET Framework 3.5 SP1, there have been a lot of questions from ASP.NET developers about how these two features relate to each other and when to use each. This article describes the differences between these two technologies and provides guidance for Web developers on when to use IIS URL rewriting and when to use ASP.NET routing.
IIS 7.0 Request Filtering and URL Rewriting – IIS 7.0 includes a request filtering module that is based on the URLScan ISAPI Filter for IIS 6.0. The module helps you tighten security of your Web servers. The URL rewrite module, even though its primary purpose is to rewrite URL paths for requests, can also be used as a security enforcement tool that helps prevent access to Web site content. The article compares security related features of these two modules and explains how to choose among them when securing your web server.

Please take a look and leave comments or questions if anything is not clear or you would like to get more information on a particular topic.

Acknowledgements: I want to thank Phil Haack from ASP.NET team and Nazim Lala from IIS team for reviewing the articles and providing great feedback. Also I thank Mike Pope for very high quality editing of the articles.

Update for IIS 7.0 FastCGI module

IIS team has recently released an update for IIS 7.0 FastCGI module that fixes compatibility problems with several popular PHP applications. In particular, the update changes the behavior of FastCGI module in the following ways:

REQUEST_URI server variable set by FastCGI module now includes query string and path info. Previously, lack of the query string in this server variable caused the popular CMS application Drupal to not work with FastCGI on IIS 7.0
REQUEST_URI server variable now contains the originally requested URL path before any URL rewriting was performed. Prior to this fix, the server variable used to contain a final rewritten URL, which caused problems when using URL rewriting to enable “pretty permalinks” for popular blog engine WordPress.

Note that above mentioned problems do not exist in IIS 6.0 FastCGI Extension, which always has been setting the REQUEST_URI server variable correctly.

The update is available for download from the following locations:

Warning: if your PHP application was coded in a way so that it relied on the REQUEST_URI server variable to contain the requested URL without a query string or to contain the final rewritten URL, then installing this update may break your application. Before applying the update, please make sure that your application does not rely on incorrect behavior of FastCGI module.

Acknowledgements: I want to thank IIS team members (Anil Ruia, Won Yoo, Yamini Jagadeesan) for providing this update and Zend Technologies team (Stanislav Malyshev) for validating the changes in FastCGI module.

Scripting URL rewrite module configuration

URL rewrite module fully utilizes extensibility of IIS 7.0 configuration system. The rewrite rules are stored in applicationHost.config and web.config files in XML format. This provides a huge benefit of being able to use rich set of IIS 7.0 management tools and API’s for managing and scripting URL rewriter configuration. For example, you can automate any configuration task, including creating, editing and deleting of rewrite rules, by:

writing .NET code that uses Microsoft.Web.Administration API’s;
writing JavaScript code;
using IIS command line tool appcmd.exe;
using PowerShell provider.

The Configuration Editor, included in the Administration Pack for IIS 7.0, greatly simplifies the process of generating scripts for automating URL rewriter configuration. In this post, I will demonstrate how to use the Configuration Editor to automate configuration of rewrite rules.

IIS.NET uses URL rewrite module

IIS.NET team has been very proactive in helping us out with testing of URL rewrite module. In fact, they even agreed to deploy the latest build of the module on the production server that hosts http://www.iis.net. This kind of real-life deployments really helps us validate the features and functionality of the module. And being able to do this validation so early in release cycle gives us a good opportunity to adjust the feature set, re-consider some of the design decisions, or just find some very good bugs.

IIS.NET has URL rewriting requirements, which are typical for large content management systems. The articles on the site are often moved or updated and the old links should continue to work. Or there is a need to have a nice URL (for example – http://www.iis.net/fastcgi) for a page that currently has some meaningless URL (e.g. http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1521). IIS.NET has more than a hundred of such URL mappings. Majority of those mappings are static, so there is no need to use regular expression patterns, capture groups, back-references or any other advanced URL rewriting stuff. Rewriting logic is very simple:- for example if input URL is “/php” then rewrite it to “/default.aspx?tabid=50001”. But if we tried to define this logic by creating a rewrite rule per URL mapping we would end up with more than a hundred of rules, which would be evaluated for every request. That would kill the performance of the web site.

Per-site PHP configuration with IIS FastCGI

There have been a few questions on IIS.NET PHP forum regarding enabling per-site PHP configuration. This is a common requirement when running PHP applications in shared hosting environment, because each PHP application may require a different set of PHP settings. Shared hosting providers often want to provide their customers with an option of controlling PHP configuration if necessary.

Until recently, it was thought that per-site PHP configuration was only possible when running PHP on Apache in *nix based OS. However, with FastCGI module it is possible to enable this for PHP applications hosted on IIS 6.0 and IIS 7.0.

The development team at GoDaddy.com has researched and validated several options for enabling per-site PHP configuration on Windows. Based on their findings, we have updated the PHP shared hosting guide with instructions on how to allow per-site php.ini files when running PHP via FastCGI on IIS 7.0. In this post I will explain how to accomplish the same on IIS 6.0 by using FastCGI extension.

Assume we have two web sites in IIS 6.0 – website1.com and website2.com. We want each web site to use its own version of php.ini file. Let’s assume that php.ini for website1.com is located in C:\Inetpub\website1.com folder and php.ini for website2.com is located in C:\Inetpub\website2.com folder.