Handling invalid problem objects

[mnot]

From https://www.rfc-editor.org/errata/eid5515 :

JSON objects with a null "type" are syntactically correct, but there is no information on how it should be handled.

{ "type": null, "status": 404, "title": "Not Found" }

It makes sense to treat null as an alias of "about:blank" and that's how I think it should be documented.

[mnot]

Note that the errata above is only Reported.

My .02 -- if type is null, it's invalid, not "syntactically correct"; it's specified to be a string, and if someone assumes that null has semantics, that's not currently specified behaviour. So the real question here is whether the default of about:blank is assumed when the value is invalid, or whether some other error handling comes into play.

I think the safest thing to do would not be to assume that null implies about:blank -- i.e., no change to the spec.

[asbjornu]

Since this is a specification of a format for error messages, I believe it is important that the processing of the error message is clear and lenient so the processing itself does not cause errors, possibly shrouding the initial error that caused the application/problem+json response in the first place.

I therefore think the specification should be explicit that all erroneous values (such as "type": null, "status": "invalid", "detail": 123, etc.) should be ignored and treated as the default value of each member, which for type equals to about:blank, but for other members equal to an empty string(?).

[mnot]

I think I agree; changing issue title.