ASP.NET MVC, Url Routing: Maximum Path (URL) Length

Question

The Scenario

I have an application where we took the good old query string URL structure:

?x=1&y=2&z=3&a=4&b=5&c=6

and changed it into a path structure:

/x/1/y/2/z/3/a/4/b/5/c/6

We're using ASP.NET MVC and (naturally) ASP.NET routing.

The Problem

The problem is that our parameters are dynamic, and there is (theoretically) no limit to the amount of parameters that we need to accommodate for.

This is all fine until we got hit by the following train:

HTTP Error 400.0 - Bad Request ASP.NET detected invalid characters in the URL.

IIS would throw this error when our URL got past a certain length.

The Nitty Gritty

Here's what we found out:

This is not an IIS problem

IIS does have a max path length limit, but the above error is not this.

Learn dot iis dot net How to Use Request Filtering Section "Filter Based on Request Limits"

If the path was too long for IIS, it would throw a 404.14, not a 400.0.

Besides, the IIS max path (and query) length are configurable:

<requestLimits


   maxAllowedContentLength="30000000"


   maxUrl="260"


   maxQueryString="25" 


              />

This is an ASP.NET Problem

After some poking around:

IIS Forums Thread: ASP.NET 2.0 maximum URL length? http://forums.iis.net/t/1105360.aspx

it turns out that this is an ASP.NET (well, .NET really) problem.

The shit of the matter is that, as far as I can tell, ASP.NET cannot handle paths longer than 260 characters.

The nail in the coffin in that this is confirmed by Phil the Haack himself:

Stack Overflow ASP.NET url MAX_PATH limit Question ID 265251

The Question

So what's the question?

The question is, how big of a limitation is this?

For my app, it's a deal killer. For most apps, it's probably a non-issue.

What about disclosure? No where where ASP.NET Routing is mentioned have I ever heard a peep about this limitation. The fact that ASP.NET MVC uses ASP.NET routing makes the impact of this even bigger.

What do you think?

Answer 1

I think you're trying to hard to use GET. Try changing the request method to POST and put those query string parameters into the request body.

Long URL does not help SEO as well, does it?

Answer 2

OK so part of the reason I posted this was also because we have found a work around.

I hope this will be useful to someone in the future :D

The workaround

The workaround is quite simple, and it's quite nice too.

Since we know which parts of the site will need to use dynamic parameters (and hence will have a dynamic path and length), we can avoid sending this long url to ASP.NET routing by intercepting it before it even hits ASP.NET

Enter IIS7 Url Rewriting (or any equivalent rewrite module).

We set up a rule like this:

    <rewrite>
        <rules>
            <rule>
                <rule name="Remove Category Request Parameters From Url">
                <match url="^category/(\d+)/{0,1}(.*)$" />
                <action type="Rewrite" url="category/{R:1}" />
            </rule>
        </rules>
    </rewrite>

Basically, what we're doing is just keeping enough of the path to be able to call the correct route downstream. The rest of the URL path we are hacking off.

Where does the rest of the URL go?

Well, when a rewrite rule is fired, the IIS7 URL Rewrite module automagically sets this header in the request:

HTTP_X_ORIGINAL_URL

Downstream, in the part of the app that parses the dynamic path, instead of looking at the path:

HttpContext.Request.Url.PathAndQuery

we look at that header instead:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

Problem solved... almost!

The Snags

Accessing the Header

In case you need to know, to access the IIS7 Rewrite Module header, you can do so in two ways:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

or

HttpContext.Request.Headers["X-ORIGINAL-URL"]

Fixing Relative Paths

What you will also notice is that, with the above setup, all relative paths break (URLs that were defined with a "~").

This includes URLs defined with the ASP.NET MVC HtmlHelper and UrlHelper methods (like Url.Route("Bla")).

This is where access to the ASP.NET MVC code is awesome.

In the System.Web.Mvc.PathHelper.GenerateClientUrlInternal() method, there is a check being made to see if the same URL Rewrite module header exists (see above):

// we only want to manipulate the path if URL rewriting is active, else we risk breaking the generated URL
NameValueCollection serverVars = httpContext.Request.ServerVariables;
bool urlRewriterIsEnabled = (serverVars != null && serverVars[_urlRewriterServerVar] != null);
if (!urlRewriterIsEnabled) {
    return contentPath;
}

If it does, some work is done to preserve the originating URL.

In our case, since we are not using URL rewriting in the "normal" way, we want to short circuit this process.

We want to pretend like no URL rewriting happened, since we don't want relative paths to be considered in the context of the original URL.

The simplest hack that I could think of was to remove that server variable completely, so ASP.NET MVC would not find it:

protected void Application_BeginRequest()
{
    string iis7UrlRewriteServerVariable = "HTTP_X_ORIGINAL_URL";

    string headerValue = Request.ServerVariables[iis7UrlRewriteServerVariable];

    if (String.IsNullOrEmpty(headerValue) == false)
    {
        Request.ServerVariables.Remove(iis7UrlRewriteServerVariable);

        Context.Items.Add(iis7UrlRewriteServerVariable, headerValue);
    }
}

(Note that, in the above method, I'm removing the header from Request.ServerVariables but still retaining it, stashing it in Context.Items. The reason for this is that I need access to the header value later on in the request pipe.)

Hope this helps!

Answer 3

Probably doens't matter now... but this worked for me (since I wasn't using aspx files, and I would venture to guess this would work for MVC):

http://blogs.iis.net/rakkimk/archive/2008/10/10/asp-net-2-0-x64-you-may-get-http-400-bad-request-or-error-as-mentioned-in-kb-932552-or-826437.aspx