1

我在 Azure 上运行 ASP.NET 4。我偶然发现了微软的这个很棒的新功能，服务器完全忽略了 URL 编码。

起初我遇到了 %26 的问题，并且收到了不允许使用 & 符号的错误。这显然是一个错误，因为 %26 in not & 并且拥有 %26 的全部意义在于能够安全地在 url 中传递它。

www.example.com/this-is-me-%26-microsoft/

我可以通过将其添加到 Web 配置来解决此问题：

   <httpRuntime requestValidationMode="2.0" executionTimeout="20" requestPathInvalidCharacters="" />
    <pages validateRequest="false"/>

这解决了 %26 问题，但现在我看到问题还远未结束，因为编码为 # 的 %23 表现得好像是 # 而不是 %23

www.example.com/%23this-should-work/

我需要永久解决这个问题。我不需要这个完全错误的请求验证。我发现这个链接讨论了这种精神错乱，但我不明白如何在网络应用程序中使用这个 URL_ESCAPE_SEGMENT_ONLY。

编辑：

从 2009 年找到此链接： 看起来这个问题现在已经持续了一段时间，但由于微软不在乎，所以正在做记录...

编辑2！！！：

经过一整天的工作并尝试了在互联网上找到的所有可能的解决方案/解决方法（足以写一整本书），我已将其隔离为一个非常具体的错误。我的幸运是，测试用例 url 的开头是 %23，就像这样。

http://www.example.com/%23eleven/

事实证明，如果 %23 位于段的开头，它会自动取消转义并处理为 # 并且世界上没有办法改变这一点。

为了说明这一点，只需运行以下命令：

Response.Write(Request.Url.GetComponents(UriComponents.SerializationInfoString, UriFormat.UriEscaped));

在具有流动 URL 的页面中

http://www.example.com/%23elevenand%23noteleven/

响应写入将输出：

http://www.example.com/#elevenand%23noteleven/

另外，如果您这样做：

Response.Write(Request.Url.GetComponents(UriComponents.Fragment, UriFormat.Unescaped));

结果将是：

elevenand#noteleven/

PS 除了这个特殊的错误，我在调试的一整天中学到的是，.NET 中的整个 URL 编码和解码在所有旧版本（.NET 4 之前）和所有新版本中都是一场彻底的灾难.NET 4 修改是更大的灾难，就像火上浇油一样。它没有按应有的方式工作，有大量用户报告此问题的帖子，但微软忽略了所有内容，并将报告的错误关闭为已解决和重复。

4

0 回答 0