URL rewriting with UrlRewritingNet fails with a + char in the URL

Question

I'm using UrlRewritingNet in Umbraco to do some basic URL rewriting of product and category URLs. Everything is fine on my local machine (Visual Studio dev-webserver) and on our internal development server (Window Server 2008 with ISS 7, 32 bit). But it fails on the production server, which is Window Server 2008 R2 with IIS 7 (64 bit). The symptom is that the rewrite rule is not triggered. The server simply gives me an 404 error.

The rewriting rule looks like this:

<add name="CategoryRewrite"
     virtualUrl="^/products/(.*)/(.*).aspx"
     rewriteUrlParameter="ExcludeFromClientQueryString"
     destinationUrl="~/default.aspx?umbPage=1&amp;maincategory=$1&amp;subcategory=$2"
     ignoreCase="true"/>

The URL looks like the following - this doesn't work:

http://example.net/products/category+name/sub+category.aspx

If I change the URL to the following it works in all 3 environments:

http://example.net/products/category%20name/sub%20category.aspx

It is clear that the regex in the virtualUrl attribute fails when the + is used for the space character. But I must admit, that I can figure out why the regex fails only on the Windows 2008 R2 server.

I'm looking for insights on what differences between the Windows Server 2008 R2 and the other 2 environments. What should I look for?

I have confirmed that the System.Web.RegularExpressions.dll is the same version on the servers.

Answer 1

The problem is that the IIS7 request filter rejects URLs containing + characters. The solution is add the following to you Web.config:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering allowDoubleEscaping="true" />
  </security>
 </system.webServer>
</configuration> 

For further details: http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx

A coworker got the bright idea to run the website on his own IIS. And then the error was further defined as a 404.11, and from there on a solution was simple.

Answer 2

That seems strange to me because your regex matches also '+' characters. Maybe the problem is because of the first character in the regex, beginning of string '^' that you are using. Maybe on the production server you get an absolute URL and on your dev environment server a relative URL passed into the rewriting module.