以 %20 结尾的 URL 存在问题

Posted 2023-02-22

【中文标题】以 %20 结尾的 URL 存在问题

【英文标题】：Problem with a URL that ends with %20

【发布时间】：2010-11-10 17:39:16

【问题描述】：

我有一个大问题。现场有设备发送 URL“/updates”。这是这些设备的开发人员的错字。在服务器日志中，它看起来像“/updates+”。

我有一个 ManageURL 重写模块，可以处理所有请求而无需扩展。但是这个请求会导致 HttpException：

System.Web.HttpException:

System.Web.HttpException
   at System.Web.Util.FileUtil.CheckSuspiciousPhysicalPath(String physicalPath)
   at System.Web.HttpContext.ValidatePath()
   at System.Web.HttpApplication.ValidatePathExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

正如我在日志中看到的，URL 重写模块甚至没有得到这个 URL，所以我无法在那里修复它。

有没有办法用 ASP.NET 处理这些 URL？

【问题讨论】：

我们需要查看生成异常的代码。

您是在使用 IIS 重写模块还是您自己编写的模块来进行重写？

【参考方案1】：

如果您可以访问代码，为什么不检查末尾的“+”并将其删除？

【参考方案2】：

根据some，这是在System.Web.dll：

internal static void CheckSuspiciousPhysicalPath(string physicalPath)

  if (((physicalPath != null) && (physicalPath.Length > 0))
    && (Path.GetFullPath(physicalPath) != physicalPath))
  
    throw new HttpException(0x194, "");
  

我猜你不能改变它，但不能在 IIS 设置中禁用它吗？当然，这也会禁用所有其他检查... :-(

或者编写一些在上述代码之前运行的 ISAPI 过滤器？根据Handle URI hacking gracefully in ASP.NET 所说，编写自己的模块很容易。

或者，create your own error page。在此页面（如上面的 URI hacking 链接中建议的那样）在exception.TargetSite.Name 中搜索特定文本，例如CheckSuspiciousPhysicalPath，如果找到（或总是）查看current.Request.RawUrl 或类似内容，清除错误并重定向到修复后的 URL？

【讨论】：

谢谢。抱歉这么久没有回答。作为临时修复，我们创建了一个 404 页面。并找到一种在设备上进行更改的方法。无论如何，这个错误促使我找到一个可以处理这些问题的 ISAPI 模块。

欢迎回来 ;-) 实际上，我猜 Cheeso 关于使用 ISAPI 重写过滤器的回答可能是一个简单的解决方法。然后希望在执行上述代码之前运行 —— 但我认为 Cheeso 是该过滤器的作者，我相信作者最了解。 Cheeso 的答案只有我一个赞成票，所以：你读过那个答案了吗？

@AlfeG：只是为了回答 “我猜你无法改变” >> 你实际上可以，通过注册PreSendRequestHeaders。查看我新添加的答案，或查看***.com/questions/429963/…

（很好，@Abel。另请参阅How do comment @replies work?AlfeG 没有收到您的评论通知，但会收到您的新答案通知，所以现在没问题。）

（啊，我明白了。所以在这种情况下，只使用@AlfeG会警告他，指定多个用户不会。Tx解释）

【参考方案3】：

您可以运行 URL 重写 ISAPI，例如 IIRF。

【讨论】：

IIRF 不是我们应用的理想解决方案。我正在等待 2.0 版本的发布。

IIRF 2.0 已经发布并可用，但不是最终版本。但是在 IIRF v2.0 的重写引擎中没有什么是您在 IIRF v1.2.16 中无法获得的。

就像我在我自己的答案的 cmets 中所写：我假设 IIRF 在 IIS 中的任何内置安全性之前运行？因此，在处理对 IIS 的控制之前，可以完全重写任何 URL（或者：只是去除错误的尾随空格），因此在调用 CheckSuspiciousPhysicalPath 之前。正确的？对我来说似乎是一个很好的解决方案，但仍然是我的唯一赞成票。我错过了这里的重点吗？

@Arjan，不，我认为您没有错过重点。您是正确的，ISAPI 过滤器将在 System.Web.dll 检查可疑路径之前运行。我对 IIRF v2.0 的评论是针对 AlfeG，他说他正在等待 v2.0。我想说，出于重写目的，等待是没有意义的。 IIRF v1.2 或 v2.0 都将实现目标。

跟我想的完全一样。 （我确实明白你在回复 AlfeG，但我只是不明白为什么 AlfeG 认为 IIRF 不是一个简单的解决方案，即使只是删除一个空格......毕竟不是一个大问题?)

【参考方案4】：

好的，这是一个旧线程，但我想添加一个适用于所有 ASP.NET 版本的可行解决方案。看看this answer in a related thread。它基本上归结为在global.asax.cs 中注册事件PreSendRequestHeaders。

或者，在 ASP.NET 4.0 或更高版本上，在 web.config 中使用 <httpRuntime relaxedUrlToFileSystemMapping="true" />。