IIS7/7.5 URL Routing Issue: Handling Plus Signs (+) in Base Path (Not QueryString) – ASP.NET Handler Failure Analysis


2 views

While migrating an application from IIS6 to IIS7.5, we discovered a peculiar routing behavior when URLs contained plus signs in the base path (not the querystring). Requests like http://example.com/doc+name.aspx that worked perfectly in IIS6 suddenly returned 404 errors in IIS7+ before reaching ASP.NET handlers.

Test files created for verification:

test_normal.aspx
test_with+plus.aspx
test_with%2bplus.aspx
test_with space.aspx

Observation matrix:

URL Format IIS6 IIS7/7.5
/test_with+plus.aspx 200 OK 404
/test_with%2bplus.aspx 200 OK 404
/test_with space.aspx 404 404

The key difference lies in how IIS7+ handles URL normalization before passing to handlers:

  1. IIS6: Minimal preprocessing → Direct handler mapping
  2. IIS7+: Aggressive URL validation → Early rejection

Option 1: RequestFiltering Relaxation

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

Option 2: URL Rewrite Workaround

<rule name="PlusSignHandler" stopProcessing="true">
  <match url="^(.*)\+(.*)\.aspx$" />
  <action type="Rewrite" url="{R:1}%2b{R:2}.aspx" />
</rule>
protected void Application_BeginRequest(object sender, EventArgs e)
{
    string path = Request.Url.AbsolutePath;
    if (path.Contains("+") && !path.Contains("%2b"))
    {
        Context.RewritePath(path.Replace("+", "%2b"));
    }
}
  • Solution impacts server-wide behavior
  • Potential security implications of allowing double escaping
  • Client-side URLs must maintain consistency
  • Consider URI design alternatives if possible

For permanent solutions, consider redesigning URI schemes to use hyphens or underscores instead of plus signs where possible.


When migrating from IIS6 to IIS7/7.5, developers encounter a specific URL routing issue where paths containing plus signs (+) in the base URL (not query strings) fail to reach ASP.NET handlers. This manifests as 404 errors before the request even hits the application pipeline.

Example failing URLs:
http://example.com/file+name.aspx
http://example.com/folder+name/page.aspx

IIS6 correctly processes these URLs and routes them to the appropriate handler, while IIS7/7.5 appears to block them at the server level. Interestingly, this differs from query string handling where plus signs are converted to spaces.

The issue stems from IIS7+'s stricter URL validation in the Request Filtering module. By default, it treats plus signs as potentially dangerous characters when they appear in the path segment.

Add this to your web.config's <system.webServer> section:

<security>
  <requestFiltering>
    <fileExtensions allowUnlisted="true" />
    <verbs allowUnlisted="true" />
    <hiddenSegments>
      <remove segment="+" />
    </hiddenSegments>
  </requestFiltering>
</security>

For global IIS configuration, use this AppCmd command:

appcmd set config /section:requestFiltering /-hiddenSegments.[segment='+']

If configuration changes aren't possible, consider these approaches:

  1. URL rewrite module to transform plus signs:
<rule name="PlusSignHandler" stopProcessing="true">
  <match url="^(.*)\+(.*)\.aspx$" />
  <action type="Rewrite" url="{R:1}%2b{R:2}.aspx" />
</rule>
  1. Custom HTTP module to intercept requests:
public class PlusSignModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += (sender, e) => 
        {
            var app = (HttpApplication)sender;
            if(app.Request.RawUrl.Contains("+"))
            {
                var newUrl = app.Request.RawUrl.Replace("+", "%2b");
                app.Context.RewritePath(newUrl);
            }
        };
    }
}

Create these test files in your web root:

test_normal.aspx
test_with+plus.aspx
test_with%2bplus.aspx
test_with space.aspx

Then verify access through both direct browser requests and server-side handlers.

Before allowing plus signs in URLs, consider:

  • Potential path traversal vulnerabilities
  • Double-encoding attacks
  • Impact on existing URL authorization rules

Always test these changes in a staging environment before production deployment.