43

For any URL with a plus sign (+) in the base URL (not the querystring), IIS7 and IIS7.5 (Windows Server 2008 and 2008 R2) do not appear to forward the URL to the default handler on an ASP.NET application. I started noticing the issue with a custom HTTP handler on *.html but I have the same issue with *.aspx. IIS6 (Server 2003) has no problem with these same URLs.

To replicate the issue, in an ASP.NET site, I created a set of ASPX files that did a simple Response.Write with various names:

  1. test_something.aspx
  2. test_some+thing.aspx
  3. test_some thing.aspx

The third file was a test to see if IIS7[.5] was treating plus symbols as spaces (as it would in the querystring); this does not appear to be the case. With all of these files in place, hitting http://somehost/test_some+thing.aspx or http://somehost/test_some%2bthing.aspx will work fine in IIS6 but 404 in IIS7/IIS7.5 before getting to any ASP.NET handler. Is there some configuration in IIS7/7.5 that I am missing to get it to "see" a plus sign in the URL without missing the final extension used to determine an HTTP handler?

patridge
  • 982
  • 1
  • 10
  • 15

2 Answers2

44

After searching for more combinations of IIS and plus, it appears that IIS7[.5] is set up to reject URLs with a plus sign by default out of some fear of the use of that character; that symbol is still allowed in the querystring, though. The solution is to alter the requestFiltering attribute default on <system><webServer><security><requestFiltering> to allow doubly-encoded characters with a command line call (ultimately modifying your ASP.NET web.config):

%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true

This may be a bit more dangerous than one prefers to be with their web site, but there didn't appear to be a way to be more specific than a blanket allow. The warnings were regarding the mismatching that could occur between using a plus in a URL and its typical translation as a space. It looks like the only other alternative is to stop using plus characters in your URLs at all.

patridge
  • 982
  • 1
  • 10
  • 15
  • 2
    Just an FYI: You don't have to do this on the root level template. This can be done in any Web.config file or applied to a subfolder with a tag. – mdonatas Aug 07 '17 at 12:46
  • In IIS Manager: Sites => YourSite => Request Filtering => Edit Feature Settings... => Check Allow double escaping => OK – diynevala Nov 07 '19 at 10:43
10

I just figured out how to make a rewrite rule to convince IIS7 to map pluses to spaces in URLs. In my case it was to keep legacy bookmarks or hyperlinks working.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <security>
      <requestFiltering allowDoubleEscaping="True" />
    </security>
    <rewrite>
      <rules>
        <rule name="RewriteUserFriendlyURL1" stopProcessing="false">
          <match url="\+" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="{UrlDecode:{REQUEST_URI}}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

See my blog post for further details and references.

James Skemp
  • 862
  • 2
  • 10
  • 21
Nathan
  • 360
  • 1
  • 5
  • 10
  • 1
    I solved an issue where I had to support legacy URLs with plus signs in the query string using just the security section above i.e. setting allowDoubleEscaping to "True". – stephen May 17 '12 at 13:26
  • I have a unique case - some legacy url's have two sequential plusses, ie "++". IIS seems to have a special rule against this. any ideas? – boomhauer Sep 18 '15 at 17:42
  • @boomhauer you may need to write a handler... or use a different webserver to host those URLs? One time I made Apache mod_rewrite handle a bunch of legacy URLs and redirect them to various new places, and it seemed a little more flexible. – Nathan Sep 19 '15 at 00:21