为什么 HttpRequestValidationException 有 500 个 http 错误代码而不是 400？答案

【问题标题】：Why HttpRequestValidationException has 500 http error code instead of 400?为什么 HttpRequestValidationException 有 500 个 http 错误代码而不是 400？
【发布时间】：2016-01-28 10:31:32
【问题描述】：

当我基于 MVC5 测试我的网络应用程序时，我发现 HttpRequestValidationException 从 GetHttpCode() 返回 500。
我在对服务器请求的安全测试期间捕获了这个异常。 MVC 执行请求验证并抛出此异常，我在 Application_Error 中处理它并返回 500 代码，但实际上，如果用户将错误的输入传递给服务器，我应该返回 400 错误（错误请求）。所以不明白为什么异常有500错误。我哪里错了？

【问题讨论】：

标签： c# http iis asp.net-mvc-5

【解决方案1】：

500 被认为更合适的原因有四个。

其中一个原因是尚不清楚HttpRequestValidationException 何时发生谁做错了事。可能是用户非常清楚地发送了一些不正确的东西，但也有可能是服务器错误地拒绝了一些完全没问题的东西。考虑到这是许多可能恶意请求的默认行为，很可能大多数情况下它是响应非恶意请求（用户没有积极尝试执行网站伤害）属于这一类。因此，它可能是应该考虑 4xx 或 5xx 的东西，而 5xx 是一个很好的假设（当您不确定这是客户的错时，不要责怪客户）。
当它发生在非恶意情况下时，它通常需要开发人员的注意，这仅适用于 4xx 代码（404 可能需要开发人员注意，因为 404 是由同一个站点，但可能不是）。从 500 条回复中得到的那种反馈更合适。
通用模型 ASP.NET 开始时几乎将所有异常映射到 500 个响应，这在很多时候确实有意义。 MVC 已经（明智地）用更多映射到其他错误条件的异常替换了它，但 HttpRequestValidationException 早于 MVC。

现在已经提出了这些观点，我不能说我同意其中任何一个。我仍然会说HttpRequestValidationException 表示客户端错误，如果它被错误识别为这样，那么它仍然被识别为这样，所以它显然是 400。

不过，最后的原因是：

虽然 RFC 7231 中对 400 状态的描述似乎很清楚地涵盖了此类请求，但 RFC 7231 于 2014 年发布。HttpRequestValidationException 并且对它的处理至少可以追溯到 2003 年，当时 RFC 2616 是相关的 RFC .根据该 RFC 中对 400 的描述，400 可以被解读为仅与实际 HTTP 消息格式错误的请求有关。虽然有些人确实更普遍地使用 400 作为包罗万象的“客户做错事”响应，但并不完全清楚这样做是否正确。

尽管这说明了为什么 500 可能是 1.5 年前更合适的反应，而不是为什么应该保留它。更改它虽然会产生向后兼容性的影响，所以可能不是一个好主意。

不过，如果您正在编写的给定应用程序有意识地使用 HttpRequestValidationException（而不是完全用您自己使用不同方法的验证覆盖），那么捕获此类异常并发送 400 而不是 500 是明智的.

【讨论】：

好帖子！谢谢。我发回了@Ofiris 提到的 400 个利用方法。

【解决方案2】：

这正是 MVC 对待 HttpRequestValidationException 的方式，我也不喜欢它，但你可以手动将其更改为 BadRequest：

protected void Application_Error()
{
    var lastError = Server.GetLastError();
    if (lastError is ArgumentException || lastError is HttpRequestValidationException)
    {
        Server.ClearError();
        Response.StatusCode = (int) HttpStatusCode.BadRequest;
    }
}

【讨论】：