为什么一些“潜在危险的 Request.Path”HttpExceptions 会忽略 httpErrors 设置？答案

【问题标题】：Why do some 'potentially dangerous Request.Path' HttpExceptions ignore httpErrors settings?为什么一些“潜在危险的 Request.Path”HttpExceptions 会忽略 httpErrors 设置？
【发布时间】：2015-02-23 23:23:14
【问题描述】：

我有一个 .Net 网站，其中包含使用 web.config httpErrors 部分配置的自定义错误页面：

<httpErrors errorMode="Custom" existingResponse="Replace">
  <clear/>
  <error statusCode="400" path="/page-not-found/" responseMode="ExecuteURL" />
  <error statusCode="404" path="/page-not-found/" responseMode="ExecuteURL" />
  <error statusCode="500" path="/error/" responseMode="ExecuteURL" />
</httpErrors>

和

<httpRuntime requestValidationMode="2.0" targetFramework="4.5" />

当我访问http://www.example.com/< 时，该站点会显示正确的“找不到页面”页面，但是如果我访问http://www.example.com/<a，它会显示一个带有 500 状态代码响应标头的 YSOD。

我已经连接了 Elmah，并且可以预见两个 URL 都会抛出完全相同的错误 System.Web.HttpException: A potentially dangerous Request.Path value was detected from the client (<).

但是为什么两个 URL 的处理方式不同呢？为什么一个被重写到我的自定义错误页面，而另一个没有？我希望任何异常都有相同的行为。

编辑：

我应该提前提到这是一个 Umbraco 项目。我认为这不是促成因素，但我创建了一个没有依赖项的准系统 .Net 项目，并且按预期工作，即两个 URL 都遵循 httpErrors 配置。所以这一定是 Umbraco 特有的东西，可能是一个模块。

【问题讨论】：

标签： asp.net exception configuration umbraco

【解决方案1】：

validate 辅助方法首先调用输入验证，然后调用路径。

在验证来自位于“syste.web/httRuntime”requestPathInvalidCharactersArray 属性的默认 web.config 设置的输入时，在默认配置中为 validate 辅助方法设置的默认值是：

,*,%,&,:,\,?

来源：https://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestpathinvalidcharacters(v=vs.110).aspx

如您所见，“

如果您对我是如何得出这个结论感到好奇，我只是查看了 validate 辅助方法的源代码，然后将其返回到源代码。

[编辑]

ValidateInputIfRequiredByConfig 方法显示它抛出 400

[编辑 2]

   public NameValueCollection QueryString
    {
        get
        {
            this.EnsureQueryString();
            if (this._flags[1])
            {
                this._flags.Clear(1);
                this.ValidateHttpValueCollection(this._queryString, RequestValidationSource.QueryString);
            }
            return this._queryString;
        }
    }

如果验证源是 Querystring，则调用此属性命中 ValidateHttpValueCollection 可以验证查询字符串，它在此属性中。

在这个方法中有一个方法叫做ValidateString。在 ValidateString 中，它确定它是否是有效字符串，如果不是，则抛出 HttpRequestValidationException

【讨论】：

我不认为这是正确的。查看堆栈跟踪并将其引用到 .Net source 很明显，异常正在ValidateInputIfRequiredByConfig() 的同一点引发。我需要知道的是为什么会抛出 500 状态码错误而不是预期的 400？
一个是无效路径（在 url 中）并产生 400 因为找不到它，对吗？另一个是 500，因为它是无效输入。源代码中的代码也反映了这一点。
不，那是不正确的。 400 是一个不“未找到”的错误请求，该方法中没有任何内容会引发 500 异常，只有 400。最后，第 2612 行将捕获两条路径，因此将在第 2615 行抛出。那么抛出 500 的原因是什么？
我用另一个潜在原因更新了答案。请参阅编辑 2。
感谢您在这方面的时间，但它失败的不是QueryString，而是Path 属性。你是对的 is 通过 IsDangerousString() 方法抛出一个 HttpRequestValidationException ，这将解释 500 状态。然而，问题仍然存在。为什么会忽略 httpErrors 配置？

【解决方案2】：

经过大量挖掘，我可以看到这实际上是由名为 ClientDependency 的第 3 方模块引起的。删除这个并返回正常行为，但显然在这种情况下后台将无法正常运行。

需要该项目的补丁，我已提交此补丁。

更新：

从 v1.8.3 开始，ClientDependency 中的此错误已得到修复

【讨论】：