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?

  • I wonder if escaping the plus sign would help. Maybe \+? Oct 19, 2009 at 19:10

2 Answers 2


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.

  • 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 <location /> tag.
    – mdonatas
    Aug 7, 2017 at 12:46
  • 1
    In IIS Manager: Sites => YourSite => Request Filtering => Edit Feature Settings... => Check Allow double escaping => OK
    – diynevala
    Nov 7, 2019 at 10:43

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"?>
      <requestFiltering allowDoubleEscaping="True" />
        <rule name="RewriteUserFriendlyURL1" stopProcessing="false">
          <match url="\+" />
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          <action type="Rewrite" url="{UrlDecode:{REQUEST_URI}}" />

See my blog post for further details and references.

  • 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, 2012 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, 2015 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, 2015 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.