RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 7807, "Problem Details for HTTP APIs", March 2016

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

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.

Report New Errata