HTTP Warning header

[Jaymon]

Should Endpoints use these for error message? It might be deprecated

Links:

• RFC 2616 14.46 Warning
• RFC 2047
• Warning - This says warning header is soon to be deprecated
• SO Putting detailed REST error message in HTTP Warning header, good/bad idea?

[jgrisham]

The new draft justifies depreciation based on a claim that all mainstream user agents ignore that header.

So, using it shouldn’t harm anything (but there’s always the risk it could be re-activated in the future so its probably best to follow the existing semantics).

---

There were several revisions of an Internet Draft (that expired last spring) (on GitHub) that was aiming to provide something similar for API usage.

---

Edit: there appears to be a standards-track RFC purpose-made for this sort of thing: RFC 7807 Problem Details for HTTP APIs

[Jaymon]

This is cool, thank you for sharing. I'll look into RFC7807 when I finally get to making the error handling better

[Jaymon]

I think json errors can use this when an Exception or list of exceptions is all that is in the Response body in development and by default:

• https://datatracker.ietf.org/doc/html/rfc9457

I think production errors could use this format but it would make more sense to return whatever is the agreed upon with the frontend.

I think the warning header can be used in systems that have debug activated or something like that, that way testing production ready systems will use the agreed error body format but if they are in the dev or staging we can set the warning header with additional information on the raised errors to help frontend debug.

When I actually get around to implementing this I think this is the direction I will go.