RFC 7807 compliant?

[max-pfeiffer]

Hi @edaniszewski ,
first of all thanks for providing that package to the community. I just reviewed your package because we think about using it in our software development operation: this is very well made.

But with looking into RFC 7807 and checking on the problem details object members at some points your implementation does not seem to be compliant:

1. exc_type
   Here you add an additional object member exc_type to the problem object. This member type is not present in the RFC documentation. So I would consider this beeing out of specs.
   Also I am asking myself why a additional object property is needed here. When I read the specs I think that exception name could be just added to the title property of the problem object:

"title" (string) - A short, human-readable summary of the problem
type. It SHOULD NOT change from occurrence to occurrence of the
problem, except for purposes of localization (e.g., using
proactive content negotiation; see [RFC7231], Section 3.4).

2. errors
   The errors object member also do not exist in the RFC 7807 specification. Looking at the detail object property and your implementation. I am asking myself why the errors aren't just rendered as a string and concatenated to the detail string as this should be "specific to the occurence of the problem":

"detail" (string) - A human-readable explanation specific to this
occurrence of the problem.

Maybe you can let me know your thinking behind these implementations. Especially not so sure what your thinking was with regard to that specific parts of the RFC 7807 I quoted above. There might have been good reasons to do it like this, but I don't know.

Regards, Max

[arbakker]

@max-pfeiffer I am not the author, but I am currently looking at this library and the spec. According to the spec it is allowed to extend the problem details object with additional fields, see https://datatracker.ietf.org/doc/html/rfc7807#section-3.2

[max-pfeiffer]

@arbakker Thanks for pointing that out.