IIS 对第一个请求和后续请求中 URL 中双编码正斜杠的处理方式不同

Question

最近，我的团队被要求为 ASP.NET MVC 应用程序实现一个 HttpModule，该应用程序处理 IIS 7 和 .NET 3.5 上的双编码 URL。问题的关键在于：

我们有时会得到具有双编码正斜杠的 URL，如下所示：

http://www.example.com/%252fbar%5cbaz/foo

我们还必须处理其他格式，但它们都有一些共同点，它们都有一个双编码正斜杠削减。

为了解决这个问题，我们编写了一个 HttpModule，它仅在 URL 具有双编码正斜杠时才起作用，并且我们将其重定向到正常的 URL。细节并不重要，但有两点是：

1. 我们无法控制这些 URL 具有双重编码的正斜杠这一事实
2. 我们还没有升级到 .NET 4.0，也不会立即升级。

问题是：

IIS 启动后的第一个请求显示的 URL 与第二个请求不同。

如果我们使用上面示例中的 URL，则对 IIS 的第一个请求将如下所示：

http://www.example.com/bar/baz/foo

，第二个请求将如下所示：

< code>http://www.example.com/%252fbar%5cbaz/foo

这是通过在调试时检查 Application.Request.Url.AbsolutePath 属性来完成的。

下面是应该重现该问题的最小代码示例（创建一个新的 MVC 应用程序，并注册以下 HttpModule）：

public class ForwardSlashHttpModule : IHttpModule
{
    internal IHttpApplication Application { get; set; }
    
    public void Dispose()
    {
        Application = null;
    }

    public void Init(HttpApplication context)
    {
        Initialize(new HttpApplicationAdapter(context));
    }
    
    internal void Initialize(IHttpApplication context)
    {
        Application = context;
        context.BeginRequest += context_BeginRequest;
    }
    
    internal void context_BeginRequest(object sender, EventArgs e)
    {
        var url = Application.Request.Url.AbsolutePath; //<-- Problem point
        //Do stuff with Url here.
    }
}

然后，在 localhost 上调用相同的 URL：

http://www.example.com/%252fbar%5c/foo

注意：请确保在 context_BeginRequest 行之前插入 Debugger.Launch() 调用，以便您能够在 IIS 首次启动时看到它

注意：请确保在 context_BeginRequest 行之前插入 Debugger.Launch() 调用，以便在 IIS 第一次启动时执行时 第一个请求，您应该看到：

http://example.com/bar/foo

在后续请求中，您应该看到：

http://example.com//bar/foo< /代码>。

我的问题是：这是 IIS 中的错误吗？为什么第一次调用 Application.Request.Url.AbsolutePath 时会提供不同的 URL，但后续请求不会提供不同的 URL？

另外：无论第一个请求是否是双重编码的 URL，第二个请求始终都会由 IIS 进行适当的处​​理（或者至少按照处理双重编码的正斜杠的方式进行处理）。问题就出在第一个请求上。

更新

我尝试了几个不同的属性来查看第一个请求是否有不同的值：

First Request

string u = Application.Request.Url.AbsoluteUri;
"http://example.com/foo/baz/bar/"
string x = Application.Request.Url.OriginalString;
"http://example.com:80/foo/baz/bar"
string y = Application.Request.RawUrl;
"/%2ffo/baz/bar"
bool z = Application.Request.Url.IsWellFormedOriginalString();
true

唯一有趣的是 Application.Request.RawUrl 发出单编码的正斜杠（% 2f），并将编码的反斜杠（%5c）转换为正斜杠（尽管其他所有东西也这样做）。

RawUrl 仍然在第一个请求时进行部分编码。

Second Request

string u = Application.Request.Url.AbsoluteUri;
"http://example.com//foo/baz/bar"
string x = Application.Request.Url.OriginalString;
"http://example.com:80/%2ffoo/baz/bar"
string y = Application.Request.RawUrl;
"/%2ffoo/baz/bar"
bool z = Application.Request.Url.IsWellFormedOriginalString();
false

第二个请求中的有趣点：

• IsWellFormedOriginalString() 为 false。在第一个请求中，它是true。
• RawUrl 是相同的（可能有帮助）。
• AbsoluteUri 是不同的。在第二个请求中，它有两个正斜杠。

更新

Application.Request.ServerVariables["URL"] = /quotes/gc/v12/CMX
Application.Request.ServerVariables["CACHE_URL"] = http://example.com:80/%2ffoo/baz/bar

未解决的问题

• 这似乎是 IIS 或 .NET 中的错误。是吗？
• 这只对应用程序在 iisreset 之后发出的第一个请求很重要。
• 除了使用 RawUrl 之外（因为如果我们解析Raw Url 而不是使用 .NET 提供的“安全”URL），我们还有哪些其他方法可以处理这个问题？

请记住，此问题的物理影响很低：要使其成为实际问题，客户端向 Web 服务器发出的第一个请求必须针对上述特定 URL，并且发生这种情况的可能性相对较低。

Answer 1

Request.Url 已经可以解码 - 我不相信它会做你正在做的事情。

内部详细信息请参见：
带有 url 编码和符号的查询字符串在 Request.Url 中过早解码

解决方案是直接通过Request.RawUrl 访问值。

我意识到你的问题与路径有关，但似乎发生了同样的事情。尝试 RawUrl - 看看它是否适合您。

Answer 2

这确实不是一个答案，但可能是朝着正确方向迈出的一步。我没有时间创建测试工具来证明任何事情。

我通过 Reflector 跟踪了 this.PrivateAbsolutePath 并且它一直持续下去。访问时有很多字符串操作。

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;
    }
}