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
RFC 7807 defines a standard response format for HTTP handling problems. Error handling in Go has always been a bit verbose, but HTTP introduces the additional step of constructing and writing a response each time, which can be very frustrating if you want to have an error that isn't 500 Internal Server Error. I would like to implement a standard ProblemResponse that takes in a ResponseWriter and fields related to 7807 (type string, title string, status code, detail string, instance string) and writes a formatted response with content type `application/problem+json. This function/type should validate that the inputs are OK according to spec (so type and instance must be URIs, etc).
Notably, this should not write a problem on panics--exposing internal errors can be a serious security issue, and the decision to use RFC 7807 or not should be a conscious one made during regular operation.
Since 7807 is a proposal, I would also like to implement an ErrorResponse that just takes in a code and an error instead of the problem fields.
The text was updated successfully, but these errors were encountered:
RFC 7807 defines a standard response format for HTTP handling problems. Error handling in Go has always been a bit verbose, but HTTP introduces the additional step of constructing and writing a response each time, which can be very frustrating if you want to have an error that isn't
500 Internal Server Error
. I would like to implement a standardProblemResponse
that takes in a ResponseWriter and fields related to 7807 (type string, title string, status code, detail string, instance string) and writes a formatted response with content type `application/problem+json. This function/type should validate that the inputs are OK according to spec (so type and instance must be URIs, etc).Notably, this should not write a problem on panics--exposing internal errors can be a serious security issue, and the decision to use RFC 7807 or not should be a conscious one made during regular operation.
Since 7807 is a proposal, I would also like to implement an
ErrorResponse
that just takes in a code and an error instead of the problem fields.The text was updated successfully, but these errors were encountered: