RFC Errata
Found 3 records.
Status: Verified (1)
RFC 7807, "Problem Details for HTTP APIs", March 2016
Note: This RFC has been obsoleted by RFC 9457
Source of RFC: appsawg (art)
Errata ID: 6178
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gary Peck
Date Reported: 2020-05-18
Verifier Name: Barry Leiba
Date Verified: 2020-05-19
Section 3 says:
The ability to convey problem-specific extensions allows more than
one problem to be conveyed. For example:
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://example.net/validation-error",
"title": "Your request parameters didn't validate.",
"invalid-params": [ {
"name": "age",
"reason": "must be a positive integer"
},
{
"name": "color",
"reason": "must be 'green', 'red' or 'blue'"}
]
}
It should say:
The ability to convey problem-specific extensions allows more than
one problem to be conveyed. For example:
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://example.net/validation-error",
"title": "Your request parameters didn't validate.",
"invalid_params": [ {
"name": "age",
"reason": "must be a positive integer"
},
{
"name": "color",
"reason": "must be 'green', 'red' or 'blue'"}
]
}
Notes:
The "invalid-params" member in the example is named incorrectly. According to Section 4, it should contain an "_" rather than a "-" in its name:
> If such additional members are defined, their names SHOULD start with
> a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist
> of characters from ALPHA, DIGIT ([RFC5234], Appendix B.1), and "_"
> (so that it can be serialized in formats other than JSON), and they
> SHOULD be three characters or longer.
Status: Reported (1)
RFC 7807, "Problem Details for HTTP APIs", March 2016
Note: This RFC has been obsoleted by RFC 9457
Source of RFC: appsawg (art)
Errata ID: 5515
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven
Date Reported: 2018-10-05
Section 3.1 says:
o "type" (string) - A URI reference [RFC3986] that identifies the
problem type. This specification encourages that, when
dereferenced, it provide human-readable documentation for the
problem type (e.g., using HTML [W3C.REC-html5-20141028]). When
this member is not present, its value is assumed to be
"about:blank".
It should say:
o "type" (string) - A URI reference [RFC3986] that identifies the
problem type. This specification encourages that, when
dereferenced, it provide human-readable documentation for the
problem type (e.g., using HTML [W3C.REC-html5-20141028]). When
this member is missing or null, its value is assumed to be
"about:blank".
Notes:
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.
Status: Rejected (1)
RFC 7807, "Problem Details for HTTP APIs", March 2016
Note: This RFC has been obsoleted by RFC 9457
Source of RFC: appsawg (art)
Errata ID: 7256
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ahmed Hussein
Date Reported: 2022-11-23
Rejected by: Francesca Palombini
Date Rejected: 2022-11-28
Section 3.2 says:
Note that because extensions are effectively put into a namespace by the problem type, it is not possible to define new "standard" members without defining a new media type.
It should say:
Note that because extensions are effectively put into a namespace by the problem type, it is not possible to define new "standard" members without defining a new problem type.
Notes:
Typo at the end of the sentence, defining extension members require defining new problem types not media types.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group.