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.

Continue reading “Wildcard script mapping and IIS 7 integrated pipeline”

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.

Continue reading “URL Rewrite Module – Go Live release”

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:

  1. 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
  2. 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:

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.

Continue reading “Scripting URL rewrite module configuration”

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.

Continue reading “IIS.NET uses URL rewrite module”

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.

Continue reading “Per-site PHP configuration with IIS FastCGI”

Introduction

My name is Ruslan Yakushev. I am a program manager on IIS team, working on some of the very interesting projects that are being developed in the team right now. I have joined the team about a year ago, and was thinking about starting a blog for a while now. The primary work responsibilities kept me busy, so I have been postponing blog idea for a while. Every time I needed to make an announcement or an update on IIS community site, I asked some of my colleagues  on the team to blog my content. Finally, I figured that I should probably start my own blog, so I could have all the freedom of publishing my own content any time I want.

Being a technical program manager on the team, I like to use (in other words – “dogfood”) the products that team develops. Hence I decided to self-host my own blog by using latest version of IIS. Also, I have been working with FastCGI and PHP for a while now, and became quite familiar with many popular PHP applications. As a result I chose to run my blog by using latest version of WordPress, which is a very nice and easy to use blog engine application. Finally, I am using my favorite feature of IIS 7.0 – URL rewriter – to enable “pretty permalinks” on my blog.

I plan to use this blog to publish information related to FastCGI, PHP, URL rewriter and IIS in general. I hope you’ll find this content useful.