current HttpApiProblem::TYPE_HTTP_RFC is not realy RFC compliant

[MIvanIsten]

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".

[veewee]

The specification encourages - but doesn't enforce - it indeed.

It is overwritable and I encourage you to do so.

[MIvanIsten]

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.