current HttpApiProblem::TYPE_HTTP_RFC is not realy RFC compliant
Bug Report
| Q | A |
|---|---|
| BC Break | no |
| Version | 1.8.0 |
Summary
Sending "type": "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" is not realy RFC compliant.
It does not identify the actual problem, has no documentation about it.
Even not sending it at all, is more compliant than sending an irrelevant URL.
https://www.rfc-editor.org/rfc/rfc7807#section-3.1
"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".
The specification encourages - but doesn't enforce - it indeed.
It is overwritable and I encourage you to do so.
It does not enforce to use it.
But sending irrelevant / invalid / useless response is against the point of RFC.
Not sending type is fine, sending an invalid url is not fine.
HttpApiProblem::$data is private, and no way provided to remove type from it.