[Docs] Purpose of ProblemDetails library

I’ve seen various mentions of Hellang.Middleware.ProblemDetails and I’m trying to figure out what it does. Regrettably, the readme and sample code don’t explain.

I suspect it catches unhandled exceptions and converts them to ProblemDetails. However that’s something that can be done in an exception middleware/filter/handler/whatever. Since this library seems really “fancy”, I’m sure it does more than just that! 😃

Can someone please tell me what this library actually “does”? Thanks!

(BTW: I’m not trolling, I really want to know. The Microsoft docs site even recommends this library.)

[khellang]

Yeah, I think that matches what I would expect 👍

Regarding the 422 status code; it’s an opinion of mine that syntactically correct, but semantically invalid requests should return back a different status code than 400 Bad Request:

From RFC 7231:

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

It’s increasingly common to use 422 Unprocessable Entity for this 😃

From RFC 4918:

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

Some people don’t like it (often because it’s part of the WebDAV RFC and not an “official” HTTP RFC (but this will soon change, with the inclusion of 422 in HTTPbis’ upcoming HTTP Semantics RFC, which obsoletes RFC 7231), so I’ve added an option to change it:

https://github.com/khellang/Middleware/blob/eb7f59cb5aaff0727466622af6230db12703a32f/src/ProblemDetails/ProblemDetailsOptions.cs#L133-L136

[lonix1]

Some more info about AddProblemDetailsConventions, based on khellang’s comments here:

• It swaps MVC’s built-in ProblemDetailsFactory to use the middleware’s configuration instead. This will give you more consistent errors, no matter where they are produced. I.e. from MVC’s invalid state filter etc.
• It turns off MVC’s built-in client error mapping, which also gives you more consistent error responses
• It tries to set the produced error response type on API controllers
• It adds a filter that makes returning pre-baked ProblemDetails instances from controllers a bit more consistent, by calling the middleware hooks