IIS treats double-encoded forward slashes in URLs differently on the first request than it does on subsequent requests

Question

Recently my team was asked to implement an HttpModule for an ASP.NET MVC application that handled double-encoded URLs on IIS 7 and .NET 3.5. Here\'s the crux of the problem

Answer 1

Request.Url can be decoded already - I wouldn't trust it for what you are doing.

See the internal details at: Querystring with url-encoded ampersand prematurely decoded within Request.Url

The solution is to access the values directly via Request.RawUrl.

I realize your prob is with the path, but it seems the same thing is going on. Try the RawUrl - see if it works for you instead.

Answer 2

This really isn't an answer, but possibly a step in the right direction. I haven't had time to create a test harness to prove anything.

I followed this.PrivateAbsolutePath through Reflector and it goes on and on. There is a lot of string manipulation when it's accessed.

public string AbsolutePath
{
    get
    {
        if (this.IsNotAbsoluteUri)
        {
            throw new InvalidOperationException(SR.GetString("net_uri_NotAbsolute"));
        }
        string privateAbsolutePath = this.PrivateAbsolutePath; //HERE
        if (this.IsDosPath && (privateAbsolutePath[0] == '/'))
        {
            privateAbsolutePath = privateAbsolutePath.Substring(1); 
        }
        return privateAbsolutePath;
    }
}