Hellang.Middleware.ProblemDetails 错误映射答案

【问题标题】：Hellang.Middleware.ProblemDetails error mappingHellang.Middleware.ProblemDetails 错误映射
【发布时间】：2022-09-24 05:22:33
【问题描述】：

我正在学习使用问题详细信息中间件找到here

我的设置一切正常，但我很好奇为什么它映射验证错误与默认状态代码不同。

为了更好地解释，在所有者提供的示例 repo 中尝试以下操作：
致电https://localhost:54547/mvc/modelstate
回复\"status\":422

在项目的Program.cs中，注释掉MVC覆盖AddProblemDetailsConventions（第46行）并再次调用
回复\"status\":400

400 是当您将ApiController 属性添加到控制器时自动插入的验证错误的默认状态代码。

之前和店主here讨论过，建议拨打AddProblemDetailsConventions

如果您想从您的 API（由中间件生成）获得 100% 一致的错误响应。

我了解中间件是控制响应错误消息的“格式”跟随RFC7870，但为什么要更改此示例案例的错误代码？ 422 比 400 更具体/更好的做法吗？

我试图寻找更多细节，但找不到任何细节。就像更改了其他映射一样，或者是否有一种方法可以为默认验证错误配置中间件映射（因为在我们的项目中，我们已经有测试套件断言 400 用于验证场景）。

错误 400 表示请求的格式不正确，就像正文或标头有问题一样。错误 422 表示查询有问题。 HTML结构很好，只是查询里面的参数有问题。

标签： c# .net asp.net-mvc api middleware

【解决方案1】：

在与您引用的作者的同一对话中，他确实提到了一种覆盖this post 中默认状态响应代码的方法。

关于422状态码；这是我的观点，语法正确，但语义无效的请求应该返回与 400 Bad Request 不同的状态码

他还提到不是每个人都可以选择遵循该约定，因此他提供了一种覆盖默认值的方法：
有些人不喜欢它（通常是因为它是 WebDAV RFC 的一部分，而不是“官方”HTTP RFC（但这很快就会改变，with the inclusion of 422 in HTTPbis' upcoming HTTP Semantics RFC，它已经过时 RFC 7231），所以我添加了一个选项来改变它：

并提供了ProblemDetailsOptions.ValidationProblemStatusCode的源代码值链接。

您可以像这样将选项值传递给配置，以将默认值更改回 400 状态代码：
services.AddProblemDetails(options =>
{
    options.ValidationProblemStatusCode = 400;
});
或者，如果您更喜欢使用示例库中的私有配置方法：
private void ConfigureProblemDetails(ProblemDetailsOptions options)
    {
        options.ValidationProblemStatusCode = 400;

        // the rest of the code setup he used in the example
    }
至于其他已更改的映射，除了setting the status code to 500 if there is no status code present 之外，我在默认配置的源代码中看不到太多。

【讨论】：