(WS2K8 R2 SP1) CheckInvalidPathChars 没有使用我的 requestPathInvalidCharacters 设置

Question

我使用 htaccess 来处理请求路径中的非法字符。在 WS2K8 R2 中，它按预期工作并将访问者路由到正确的错误页面，但是当我迁移到 SP1 时，它会在 htaccess 处理之前抛出“request.path 中存在潜在危险字符”错误。在这两个环境中，我都在使用 IIS 7.5。

为了解决这个问题，我在 web.config 中添加了 requestPathInvalidCharacters httpRuntime 属性以允许所有危险字符，如下所示：

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="" />

这可以防止向浏览器返回潜在危险的 Request.Path 错误，并允许 htaccess 处理请求；但是，CheckInvalidPathChars 仍会向应用程序日志发送“路径中的非法字符”异常，并且企业库仍会通过电子邮件发送该异常。

我的问题有三个：

1. 为什么在 SP1 中 httpruntime 设置在 WS2K8 R2 上不会这样做，但是却会超越我的 htaccess 规则？

2. 为什么 CheckInvalidPathChars 不使用我的 requestPathInvalidCharacters 设置？

3. 我如何才能防止 CheckInvalidPathChars 抛出此异常？

谢谢！

Answer 1

好吧，我找到了答案问题......

1. 这并不是说 httpruntime 在 SP1 中胜过 htaccess，而是在我们将请求重定向到错误页面后，我们用于非 ASP.NET MVC 文件的自定义 MVC 处理程序仍在运行。我们的自定义处理程序会解析请求及其文件扩展名。我们使用 Path.GetExtension 来获取扩展名，但这种方法会因原始请求中的无效字符而受阻。

在 SP1 之前，重定向后不会调用自定义 mvc 处理程序。我不确定为什么会发生这种情况，但没有继续追究，因为我们使用了一种解决方法——请参阅下面的 #3。

2. ASP.NET MVC 使用了我的设置，但后续的 Path.GetExtension 调用却没有。

3. 我们最终编写了自己的 GetExtension 方法，该方法与 MS 方法完全相同，只是没有检查无效字符。虽然不太美观，但可以完成工作...