You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs indicate that when overriding the default Recovery.Formatter, it's possible to set response headers. I'm currently attempting to set the Content-Type header to application/json, however it appears that doesn't stick and reverts to text/plain; charset=utf-8.
My initial thought is to move that call into the default PanicFormatter and require library users overriding the Formatter to set their own response code. This would, however, make it more of a PanicHandler than a PanicFormatter so perhaps one solution is to introduce a new PanicHandler field and deprecate the `PanicFormatter. This would also allow us to preserve compatibility.
I'll think about this a bit more, but suggestions welcome!
Your suggestion of introducing a PanicHandler and deprecating the PanicFormatter sounds good to me. If we could also preserve writing the default 500 Internal Server Error response status, unless ResponseWriter.WriteHeader() is called within PanicHandler, that would also be ideal.
The docs indicate that when overriding the default
Recovery.Formatter
, it's possible to set response headers. I'm currently attempting to set theContent-Type
header toapplication/json
, however it appears that doesn't stick and reverts totext/plain; charset=utf-8
.Example:
$ curl -i localhost:3003 HTTP/1.1 500 Internal Server Error Date: Fri, 16 Nov 2018 20:32:32 GMT Content-Length: 18 Content-Type: text/plain; charset=utf-8 {"error":"oh no!"}
The text was updated successfully, but these errors were encountered: