ProblemDetails: make httpstatuses problem types optional

I just installed the ProblemDetails middleware, which was really easy by the way, and this is my first feedback.

The first thing I tried after installation was doing a GET for a non-existent API which would normally result in a 404 and an empty body. Instead I got a 404 and a problem detail document. Great!

{
    "type": "https://httpstatuses.com/404",
    "title": "Not Found",
    "status": 404,
    "detail": null,
    "instance": null
}

What I didn’t expect was the problem URI that links to httpstatuses.com. I checked the RFC and it seems to agree with me that you shouldn’t have a custom problem URI for generic errors.

(…) truly generic problems – i.e., conditions that could potentially apply to any resource on the Web – are usually better expressed as plain status codes. For example, a “write access disallowed” problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.

https://tools.ietf.org/html/rfc7807#section-4

This specification reserves the use of one URI as a problem type:

The “about:blank” URI [RFC6694], when used as a problem type, indicates that the problem has no additional semantics beyond that of the HTTP status code.

https://tools.ietf.org/html/rfc7807#section-4.2

So my recommendation is to just leave off the problem type and let it default to about:blank for generic errors. At least make it configurable using ProblemDetailsOptions.

{
    "title": "Not Found",
    "status": 404,
    "detail": null,
    "instance": null
}

[sliekens]

Here’s how I use it:

options.MapStatusCode = statusCode => new StatusCodeProblemDetails(statusCode)
{
    Type = "about:blank"
};

or

options.MapStatusCode = statusCode => new StatusCodeProblemDetails(statusCode)
{
    Type = null // not recommended if JsonSerializerSettings.NullValueHandling is "Include"
};

[sliekens]

Perfect, thanks.