Description
Describe the bug
The usage of the ProblemDetails
is inconsistent throughout the library. There is no green line when it is actually used and not when using standard ASP.NET Core logic. In addition the flag SuppressMapClientErrors
is equally inconsistent in its usage as well.
The documentation states:
When the compatibility version is 2.2 or later, MVC transforms an error result (a result with status code 400 or higher) to a result with
ProblemDetails
.
It also states that:
The automatic creation of a
ProblemDetails
for error status codes is disabled when theSuppressMapClientErrors
property is set totrue
In my experiments (I must admit I haven't tried ALL scenarios) I found:
NotFound
andUnauthorized
appliesProblemDetails
dynamically based onSuppressMapClientErrors
setting.ValidationProblem
andProblem
will always applyProblemDetails
no matter of theSuppressMapClientErrors
setting.BadRequest
andUnprocessableEntity
appliesProblemDetails
dynamically based onSuppressMapClientErrors
setting- However; when passing
ModelState
to these they always plainModelState
result.
- However; when passing
- Unhandled exceptions in controllers does not apply
ProblemDetails
information both in Development and Production mode.
Expected results
Basically:
Applying
ProblemDetails
to all results above400
should be based on theSuppressMapClientErrors
setting.
BadRequest
andUnprocessableEntity
should always handle result the same way no matter input. That is, honor theSuppressMapClientErrors
setting and returnProblemDetails
based on that.- Unhandled exceptions should honor the
SuppressMapClientErrors
as well. - The
Problem
should in my opinion applyProblemDetails
based onSuppressMapClientErrors
since this is the easiest call to return status codes that other methods doesn't cover.
I also find it a bit strange that there is a ValidationProblem
as both BadRequest
and UnprocessableEntity
covers this (if they had been working). Is it REALLY necessary if BadRequest
and UnprocessableEntity
had consistent handling?
To Reproduce
- Clone this repository
- Run it
- Answer the questions about enabling/disabling client error mapping and developer exception handling during startup
- Try out the different controller actions available in the swagger and see the problem description
Further technical details
ASP.NET Core version 5.0
dotnet --info
NET SDK (reflecting any global.json):
Version: 5.0.200
Commit: 70b3e65d53Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.200\Host (useful for support):
Version: 5.0.3
Commit: c636bbdc8a.NET SDKs installed:
5.0.100 [C:\Program Files\dotnet\sdk]
5.0.200 [C:\Program Files\dotnet\sdk].NET runtimes installed:
Microsoft.AspNetCore.All 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Visual Studio
Microsoft Visual Studio Enterprise 2019
Version 16.9.0
VisualStudio.16.Release/16.9.0+31025.194
Microsoft .NET Framework
Version 4.8.04084