Per an annoucement by Ruslan from the IIS team Keep up the great work.
“Today IIS team has released the URL Rewrite Module 2.0 for IIS 7 – Beta. This is an incremental release that includes all the features from version 1.1, and adds support for outbound response rewriting. More specifically, it can be used to:
- Replace the URLs generated by a web application in the response HTML with a more user friendly and search engine friendly equivalent
- Modify the links in the HTML markup generated by a web application behind a reverse proxy.
- Fix up the content of any HTTP response by using regular expression pattern matching
Install the URL Rewrite Module 2.0 Beta
Install with Web Platform Installer
or, download:
URL Rewrite Module 2.0 for IIS 7 – Beta (x86)
URL Rewrite Module 2.0 for IIS 7 – Beta (x64)
Note:
- URL Rewrite v1.0 and v2.0 cannot be installed side-by-side.
- URL Rewrite v1.1 and v2.0 cannot be installed side-by-side.
- If URL Rewrite v1.0 or v1.0 is already installed, uninstall it before proceeding with installing URL Rewrite Module v2.0 Beta.
New Features
URL Rewrite Module 2.0 includes the following key features:
- Rules-based response rewriting engine. Outbound rules are used to express the logic of what to compare parts of the response with and what to do if comparison was successful. Web server and site administrators can use outbound rules to define complex response rewriting logic.
- Rewriting within the content of specific HTML tags. Instead of scanning the entire response for a particular match, the rule can be configured to look only inside of certain HTML tags, such as <a>, <img>, etc. That way the pattern is greatly simplified and the process of applying the rule to the content is much faster comparing to applying the pattern to the entire response.
- Pre-conditions for outbound rules. Applying rewrite rules on every response is an expensive operation and is not necessary in majority of the cases. Pre-conditions are used to check the response metadata to determine if outbound rules evaluation should be applied.
- Setting of server variables and HTTP headers. Various IIS server variables and HTTP request headers can be set by using rewrite rules.
- Tracking capture groups across rule conditions. The conditions back-referencing logic in URL Rewrite 1.1 worked only against the last matched conditions. In v2 it is possible to configure back-referencing logic to work against all matched conditions.
- Logging of rewritten URLs. The module can be configured to log the rewritten URL in IIS W3C logs as opposed to logging an originally requested URL.
More information
Cheers
Steve Schofield
Pondering Thought 
What about Route in ASP.NET 3.5?
What about the pros/cons of these 2 technology compare to each other?
LikeLike
It breaks with a 500 error if there’s a colon or %3A in the part of the URL that is captured and rewritten. Directly entering the URL that it would be re-written to, which contains the colon, works fine. This was not a problem in v1.1.
LikeLike
You should post the problem in the forums at forums.iis.net. I’ll report to the IIS team.
If you can post our rules in a forums post, Ruslan and company should respond.
LikeLike
I can’t speak to 3.5, you should post your question in the forums.iis.net related to IIS URL Rewrite module.
LikeLike
Sorry about posting in the wrong place. Since I already posted the problem here I may as well post the solution I found, which is to use {UrlEncode:{R:1}}. It wasn’t necessary in v1.1 but apparently is in v2.0 beta.
LikeLike
It sure would be great if you could add a hook to perform a custom action in .net before the rule is applied. I have some complex requirements that require database lookups for some of my URLs before they can be properly rewritten. Any chance of this happening?
LikeLike