【问题标题】:Suppress validation errors in ASP.NET Core's automatic 400 response抑制 ASP.NET Core 的自动 400 响应中的验证错误
【发布时间】:2026-01-08 18:45:01
【问题描述】:

虽然automatic 400 response 很有用,但我不想将验证错误发送给客户端。

这是响应正文:

{
  "errors": {
    "username": [
      "'username' must not be empty."
    ],
    ...more errors
  },
  "title": "One or more validation errors occurred",
  "status": 400,
  "traceId": "xxx:yyy"
}

但我想要的是默认值,没有错误:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "Bad Request",
  "status": 400,
  "traceId": "xxx:yyy"
}

我以为我需要做的就是设置

options.SuppressUseValidationProblemDetailsForInvalidModelStateResponses = true;

...但这并没有任何作用。

我不想禁用此功能,我只想抑制验证错误。我该怎么做?


顺便说一句,我正在使用一种解决方法,即手动创建响应正文,但我希望避免这种情况:

services.Configure<ApiBehaviorOptions>(apiBehaviorOptions => {
  apiBehaviorOptions.InvalidModelStateResponseFactory = actionContext => {
    var pd    = new ProblemDetails();
    pd.Type   = apiBehaviorOptions.ClientErrorMapping[400].Link;
    pd.Title  = apiBehaviorOptions.ClientErrorMapping[400].Title;
    pd.Status = 400;
    pd.Extensions.Add("traceId", actionContext.HttpContext.TraceIdentifier);
    return new BadRequestObjectResult(pd);
  };
});

【问题讨论】:

  • 400 表示请求本身是错误的。您所谓的解决方法是自定义 400 响应的记录方式。这不是解决方法。您在自己的问题中发布的链接中对此进行了解释
  • 您的兼容版本是多少(由SetCompatibilityVersion 设置)?
  • @PanagiotisKanavos 我认为SuppressUseValidationProblemDetailsForInvalidModelStateResponses 是这样做的方法,但它对我不起作用。它可用是有原因的,但我似乎无法让它工作。顺便说一句,我同意 400 对无效数据不是最好的,但框架就是这样做的,我会使用 422。
  • @ESG CompatibilityVersion.Version_2_2

标签: c# asp.net-core asp.net-core-2.2


【解决方案1】:

“问题详细信息”对应于 RFC 7807,它尝试标准化 HTTP API 报告错误的方式。 SuppressUseValidationProblemDetailsForInvalidModelStateResponses 并没有具体涵盖实际验证错误的返回,只是 RFC 中讨论的标准位。

做你想做的事情的唯一方法就是你已经做过的事情,即使用自定义工厂。这不是破解或解决方法:这是更改自动响应的记录方法。

也就是说,抑制验证错误绝对是零意义。整个重点是通知客户请求中存在哪些错误,以便客户可以纠正这些错误。否则,您只是关上门,没有任何迹象表明出了什么问题或如何解决它。

【讨论】:

  • 那么这是一个奇怪的命名属性 - 但感谢您确认我的方法是合适的。顺便说一句,我发现无法在 Angular 客户端和服务器之间共享验证逻辑,因此我在客户端上创建了广泛的验证,并且认为没有理由将两者联系起来......(曾几何时,使用 jquery validate 很容易)
  • 嗯,首先,客户端验证应该始终是一种渐进的增强,而不是你的万能计划。服务器端验证是您唯一可以信任的。一旦你点击了服务器,它的验证错误就会覆盖客户端发生的任何事情。此外,您不应该仅仅为了支持 Angular 应用而构建 API。这可能是它的用途,但无论客户使用它,API 都应该运行良好。如果您以后需要通过移动应用执行某些操作,则必须从头开始。