ASP.Net：尝试处理 http://localhost:5957/http://yahoo.com 时出现 HTTP 400 Bad Request 错误答案

【问题标题】：ASP.Net: HTTP 400 Bad Request error when trying to process http://localhost:5957/http://yahoo.comASP.Net：尝试处理 http://localhost:5957/http://yahoo.com 时出现 HTTP 400 Bad Request 错误
【发布时间】：2009-06-04 03:20:01
【问题描述】：

我正在尝试创建类似于 diggbar 的东西。

我正在使用 Visual Studio 2010 和 Asp 开发服务器。

但是，我无法让 ASP 开发服务器处理该请求，因为它在路径中包含“http:”。我试图创建一个 HTTPModule 来重写 BeginRequest 中的 URL，但是当 url 为 http://localhost:5957/http://yahoo.com 时，事件处理程序不会被调用。如果 url 是 http://localhost:5957/http/yahoo.com，则事件处理程序会被调用

总结一下：

http://localhost:5957/http/yahoo.com 工作
http://localhost:5957/http//yahoo.com 不起作用
http://localhost:5957/http://yahoo.com 不起作用
http://localhost:5957/http:/yahoo.com 不起作用

有什么想法吗？

【问题讨论】：

标记答案怎么样？

标签： asp.net http url-rewriting url-routing

【解决方案1】：

我在 Stefan 的帮助下写了一篇文章，解释了如何做到这一点：

Experiments in Wackiness: Allowing percents, angle-brackets, and other naughty things in the ASP.NET/IIS Request URL

【讨论】：

【解决方案2】：

来自 ASP.Net 团队的 Stefan：http://forums.asp.net/p/1431148/3221542.aspx

在当前版本的 ASP.NET Urls 中，包含冒号等字符的 URL 将被视为潜在的安全威胁而被拒绝。其历史原因是底层 NTFS 文件系统支持备用资源流，可以使用类似“yourfile.txt:hiddendata.txt”的名称访问这些资源流。阻止 Urls 中的冒号字符可防止编写不佳的应用程序意外使用备用资源流。

在当前版本的 ASP.NET 中还有一个限制，即传入的 Url 需要映射到 NTFS 文件系统以确定托管配置数据。

在 ASP.NET 4 中，可以选择删除这些限制。但是，这些更改在 ASP.NET 4 的 Beta 2 版本中 - 它们不在 Beta 1 中。我们试用了本论坛帖子前面列出的 Url，并通过我们的 ASP 内部构建确认了这一点。 NET 4，您可以使用该样式的 Url 并对其进行处理，而不会出现任何 400 错误。

-斯蒂芬

【讨论】：

【解决方案3】：

来自 ASP.Net 团队的 Stefan

我从即将发布的涵盖 Beta 2 的 What's New 文档中摘录了以下内容：

ASP.NET 4 引入了用于扩展允许的应用程序 URL 范围的新选项。最简单和最有用的更改是 ASP.NET 为开发人员提供了允许更长 URL 的选项。以前的版本将 Url 路径长度限制为 260 个字符（NTFS 文件路径限制）。在 ASP.NET 4 中，开发人员可以使用两个新的 httpRuntime 配置属性，根据他们的应用程序选择增加（或减少）这个限制：

修改“maxRequestPathLength”的值以允许更长或更短的 Url 路径（Url 无协议、服务器和查询字符串的部分）。修改“maxQueryStringLength”的值以允许更长或更短的查询字符串。ASP.NET 4 还允许开发人员调整 ASP.NET 的 Url 字符检查使用的字符集。当 ASP.NET 在 Url 的路径部分中发现无效字符时，它会拒绝请求并返回 HTTP 400 错误。在以前的版本中，Url 字符检查仅限于一组固定的字符。在 ASP.NET 4 中，开发人员可以使用另一个新的 httpRuntime 配置属性自定义字符检查集：

默认情况下，“requestPathInvalidChars”属性包含七个被认为无效的字符（小于和大于符号以及与号被编码，因为配置是一个 Xml 文件）。然后，开发人员可以根据其应用程序的需要扩展或减少无效字符集。请注意，ASP.NET 4 仍将拒绝包含 ASCII 字符范围 0x00-0x1F 中的字符的任何 Url 路径，因为这些字符被视为无效 Url 字符（RFC 2396 认为这些字符无效，并且在运行 IIS6 或更高版本的 Windows 服务器上 http. sys 协议设备驱动程序也会自动拒绝带有这些字符的 Url。

斯蒂芬

【讨论】：

【解决方案4】：

我在为 ASP.net 创建URL shortener 时遇到了这个问题。在我的一生中，我无法在客户端使用 HttpUtility.UrlEncode 或 javascript 的 escape() 以 ASP 可以接受的方式对冒号进行编码。

我的解决方案如何进行 Base64 编码。将整个事情变成无争议的字母数字。然后你在服务器上解码。我用these functions。

另外，我创建了一个由前导连字符触发的 HttpModule，因此我知道将后面的内容作为要解码的 URL 来处理。如果您想了解更多详情，请联系我。

【讨论】：

Base64 编码/解码是一种聪明的方法，但它确实会导致一些难看的 URL。

【解决方案5】：

在重定向到它之前，您需要在字符串上使用 HttpUtility.UrlEncode。

【讨论】：

问题是用户在浏览器地址栏中输入字符串。例如，用户可以输入digg.com/http://cnn.com。在那种情况下没有机会对 url 进行编码

【解决方案6】：

我不确定 digg 使用的是什么 Web 服务器，但我敢打赌这对于 IIS 或 VS 的内置 Web 服务器是不可能的。很可能它是一个可以修改为允许各种古怪 URL 的 Web 服务器。

【讨论】：

是的，看起来请求在 Web 服务器级别被抛出。不过，这似乎是一个奇怪的限制。是否有任何 MSFT IIS/ASP.Net 人员可以阐明代码库中是否存在此限制？
Spencer，感谢您修复网址。左上角有一个：digg.com/cttp://cnn.com。非常感谢。

【解决方案7】：

这不是 IIS 失败，而是 ASP 开发服务器。尝试部署到 IIS，看看它是否有效。

【讨论】：

我支持这个概念 - ASP.NET 开发服务器确实与 IIS 相比，大大减少了。
我的 IIS 7 也有同样的问题，所以我不认为这只是开发服务器的问题。

【解决方案8】：

我很确定您可以通过 IIS 重写来做到这一点。据我所知，ASP.NET 开发服务器无法进行重写，但您可以尝试使用 IIS7 重写器，或者如果您有更早的版本，请使用 Ionics ISAPI Rewrite Filter。

【讨论】：

【解决方案9】：

知识库文章 826437 (http://support.microsoft.com/kb/826437) 包含对您问题的回答

确保计算机上安装了 Microsoft .NET 1.1 SP1
在注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET 创建 VerificationCompatibility = 1 的 32 位 DWORD 值
重新启动 IIS。

它对我有用（IIS 6、ASP.NET 4），也许它也对你有用

【讨论】：

【解决方案10】：

开发环境的快速解决方案：

将 Web 项目属性更改为“使用 IIS 本地服务器”并选中“使用 IIS Express”（保留 VS 开发服务器的 URL）。
在<system.web>内的Web.config中添加以下设置：
```
<httpRuntime requestPathInvalidCharacters="" />
```

对于生产部署，请考虑其他答案中提到的安全注意事项。

【讨论】：

【解决方案11】：

我在这里回答了类似的问题。

https://stackoverflow.com/a/12037000/134761

基本上，ASP.net 只接受编码字符，如问号之后的冒号。幸运的是 ASP.net MVC 在默认映射中自动映射 /api/persons/xxxx 和 /api/persons?id=xxxx，所以这就是我最终要做的。

【讨论】：

【解决方案12】：

试试HttpUtility.UrlPathEncode(url) - MSDN Docs

【讨论】：