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

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

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

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

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

我的问题有三个方面:

  1. 为什么httpruntime设置在WS2K8 R2上没有这样做时会颠覆我的htaccess规则?

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

  3. 我怎样才能防止CheckInvalidPathChars抛出这个exception?

谢谢!

那么,我想出了答案的问题…

  1. 这并不是说httpruntime在SP1中颠覆了htaccess,而是在我们已经将请求redirect到错误页面之后,我们用于非ASP.NET MVC文件的自定义MVC处理程序正在运行。 我们的自定义处理程序分析请求及其文件扩展名。 我们使用Path.GetExtension来获得扩展,但是这个方法对原始请求中的无效字符感到窒息。

在SP1之前,自定义mvc处理程序在redirect之后未被调用。 我不知道为什么发生这种情况,但没有追求它/我们使用了一种解决方法 – 请参阅下面的#3。

  1. ASP.NET MVC使用我的设置,但后来的Path.GetExtension调用不是。

  2. 我们最终编写了我们自己的GetExtension方法,它与MS方法完全一样,没有检查无效字符。 这不是很好,但它完成了工作…