The ProblemDetails bodies produced by the result→HTTP conversions omit the Status member for several statuses, so the JSON body's status is null even though the HTTP status code on the response is correct. It is also applied inconsistently — some builders set it, others don't — and RFC 7807 §3.1 says the status member SHOULD be present and match the actual HTTP status code.
| Result status |
Minimal API (MinimalApiResultExtensions) |
MVC (ResultStatusMap) |
| 422 Error / 404 NotFound / 409 Conflict |
missing |
missing |
| 500 CriticalError / 503 Unavailable |
set |
missing |
| 403 Forbidden / 401 Unauthorized |
set |
n/a (status code only, no body) |
This matters to clients that read status off the parsed body (e.g. generated clients that throw the parsed ProblemDetails), where the HTTP status code is otherwise not readily available.
Happy to open a PR.
The
ProblemDetailsbodies produced by the result→HTTP conversions omit theStatusmember for several statuses, so the JSON body'sstatusisnulleven though the HTTP status code on the response is correct. It is also applied inconsistently — some builders set it, others don't — and RFC 7807 §3.1 says thestatusmember SHOULD be present and match the actual HTTP status code.MinimalApiResultExtensions)ResultStatusMap)This matters to clients that read
statusoff the parsed body (e.g. generated clients that throw the parsedProblemDetails), where the HTTP status code is otherwise not readily available.Happy to open a PR.