URL rewriting in general is not a new concept. It was introduced in the Apache Web server about a decade ago. Since then it has proven to be a very useful tool for web server administrators and web developers. Many popular applications hosted on Apache now rely on URL rewriting in order to enable support for "clean" URLs.

In a nutshell, the concept of URL rewriting is simple. When a client makes a request to the Web server for a particular URL, the URL-rewriting component analyzes the requested URL and changes it to a different other URL on the same server. The URL-rewriting component runs very early in the request processing pipeline, so is able to modify the requested URL before the Web server makes a decision about which handler to use for processing the request. The handler, which is then chosen based on the rewritten URL, processes the request and generates a response that is sent back to the Web browser. The requesting client never sees the rewritten URL; as far as the client is concerned, it has received a response from the original URL.

In terms of IIS 7.0 architecture, this process is represented in the following diagram:

 

The URL-rewrite module is a native-code module that plugs into the request processing pipeline at the Pre-begin Request or Begin Request stages and then evaluates the requested URL path by using a set of rewrite rules. Each rewrite rule analyzes the URL path, and if all the rule conditions are met, changes the original path to a new path. After all the rules have been evaluated, the URL-rewrite module produces a final URL path that is used for the request through the remainder of the IIS pipeline processing. This means that the handler selection in the IIS pipeline is done based on the rewritten URL that is produced by the URL-rewrite module.

ASP.NET Routing

In essence, ASP.NET routing is a request dispatching mechanism that allows developers to associate a certain URL with a handler that can process requests made to that URL. This association is done by registering the "routes" that define which handler to invoke for a particular URL path. When a request is made to a Web server, ASP.NET routing looks up the requested URL path in the list of registered routes. If the route is found, the corresponding handler for that route is invoked in order to process that request.

In terms of IIS 7.0 and ASP.NET architecture, this process is represented in the following diagram:

 

ASP.NET routing is implemented as a managed-code module that plugs into the IIS request processing pipeline at the Resolve Cache stage (PostResolveRequestCache event) and at the Map Handler stage (PostMapRequestHandler). ASP.NET routing is configured to run for all requests made to the Web application.

During the PostResolveRequestCache event, the module looks through a routing table (a collection of route objects) for a route that matches the requested URL path. If a match is found, the module gets a reference to the handler that corresponds to that route and saves the reference as part of the current HTTP context. A handler may be any .NET Framework object that implements the System.Web.IHttpHandler interface. If no route is found, the module does not do anything and the URL falls through and is processed normally (typically by matching it to a file on disk).

During the PostMapRequestHandler event, the module checks if the HTTP context contains any information about a handler. If it does, ASP.NET routing uses the information to set the Handler property of the current HTTP context. This ensures that during the Execute Handler stage, IIS will execute the handler that was selected by the routing module. If that information is not set, then once again the module does not do anything and the URL falls through to let IIS make a handler selection.

Differences between URL Rewriting and ASP.NET Routing

Based on the above explanation you can see that the main conceptual differences between URL rewriting and ASP.NET routing are the following:

1. URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
2. ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.

In addition to these conceptual differences, there are the following functional differences between IIS URL rewriting and ASP.NET routing:

1. The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
2. The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
3. The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
4. In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
5. The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.

Which Option Should You Use?

What does all this information mean if you need to choose a technology in order to enable clean URLs for your Web applications? In this section we will explain how to make this choice.

First of all, if your Web application is built by using anything except ASP.NET, the choice is obvious: use the IIS URL-rewrite module. Otherwise, the rules of thumb are:

1. If you are developing a new ASP.NET Web application that uses either ASP.NET MVC or ASP.NET Dynamic Data technologies, use ASP.NET routing. Your application will benefit from native support for clean URLs, including generation of clean URLs for the links in your Web pages. Note that ASP.NET routing does not support standard Web Forms applications yet, although there are plans to support it in the future.
2. If you already have a legacy ASP.NET Web application and do not want to change it, use the URL-rewrite module. The URL-rewrite module allows you to translate search-engine-friendly URLs into a format that your application currently uses. Also, it allows you to create redirect rules that can be used to redirect search-engine crawlers to clean URLs.

In practice, however, the choice does not have to be either/or. The technologies can be used together and can complement each other. In the following sections we outline some scenarios when you may want to use ASP.NET routing and IIS URL rewriting together.

Enforcing canonical URLs for your application. For example, you want to force the use of http://www.mysite.com/home/about instead of http://mysite.com/Home/About. When a Web client requests a URL that does not conform to the format that you want, the client is redirected to a canonical URL. In this scenario, you can use the URL-rewrite module to enforce canonical URLs and perform redirection, and use ASP.NET routing to select a handler that would process the requested URL path.

The following example shows a URL-rewrite rule that you might use for this scenario:

<rewrite>
    <rules>
        <rule name="Enforce canonical hostname" stopProcessing="true">
            <match url="(.*)" />
            <conditions>
                <add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
            </conditions>
            <action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Serving static content from a different site or server. For example, your Web application is deployed on multiple servers in such a way that dynamic Web content is located on one site or server and all static content is on a different site or server. You can use the URL-rewrite module together with the IIS Application Request Routing module to forward all the requests for static files to a different server, while serving all requests for dynamic Web pages from the current server. This way, ASP.NET routing is used only for dynamic Web content and does not evaluate any URLs for static content.

The following example shows a URL-rewrite rule that you might use for this scenario:

<rewrite>
    <rules>
        <rule name="Forward to static file server">
            <match url="^.+\.(?:jpg|bmp|gif)$" />
            <action type="Rewrite" url="http://static_file_server/{R:0}" />
        </rule>
    </rules>
</rewrite>

Static content management. When your static files or folders get moved to a new location, you still may want to support old URLs for backward compatibility reasons. In fact, may be you even do not want web sites visitors to know that the files or folders have been moved. In that case you can use URL rewrite module to rewrite paths for static files, while all the URLs to your dynamic ASP.NET web pages are handled by routing module.

The following example shows a URL-rewrite rule that may be used for this scenario:

<rewrite>
    <rules>
        <rule name="Rewrite to new folder">
            <match url="^Images/(.+)$" />
            <action type="Rewrite" url="NewImages/{R:1}" />
        </rule>
    </rules>
</rewrite>

Request blocking. URL rewrite module can be used to block certain requests based on various criteria. For example you can prevent certain site crawlers from accessing specific URL paths on your web site. That way, forbidden requests will not even get to the ASP.NET router, thus reducing the load on your web server.

The following example shows a URL rewrite rule that can be used for blocking unwanted site crawlers. Note that the requests are blocked for a particular URL path based on either user-agent HTTP header or based on client's IP address:

<rewrite>
    <rules>
        <rule name="Block SomeRobot" stopProcessing="true">
            <match url="^folder1/folder2" />
            <conditions logicalGrouping="MatchAny">
                <add input="{USER_AGENT}" pattern="SomeRobot" />
                <add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
            </conditions>
            <action type="AbortRequest" />
        </rule>
    </rules>
</rewrite>

Future Directions

Even though IIS URL rewriting and ASP.NET routing have some functional overlap, they address scenarios that are unique to each technology. Because of that, these two technologies will continue to exist and evolve as independent components in IIS with potentially tighter integration between them. For example, ASP.NET routing might leverage some of the rich tools provided with the URL-rewrite module. The URL-rewrite module might in turn be better integrated with ASP.NET in terms of providing extensibility for customizing URL rewriting logic.

Conclusion

Either IIS URL rewriting or ASP.NET routing can be used to implement URL manipulation scenarios for your Web application. ASP.NET routing is a solution that is optimized for ASP.NET, thus it may be a preferable choice for Web developers who design their ASP.NET applications from ground up to have a clean URL structure. IIS URL rewriting is a generic URL manipulation mechanism that addresses a multitude of scenarios. In particular, it can be used by Web developers as well as Web server/site administrators to enable clean URLs for existing Web applications without modifying the application code.