Distinguish between user and server errors on deserialization fail #1482
Labels
Comments
|
Some of my $work colleagues have bumped into this too. PR soon :) |
veryrusty
added a commit
that referenced
this issue
Jul 5, 2019
When a request that should be deserialized has bad content (such as invalid JSON), the serializer throws an error and returns undef. That gets caught and request object creation dies, which is then handled in the App's psgi sub resulting in a 500 error. When deserialisation fails, one typically does NOT want the client repeating the request, in which case a 400 Bad Request error would be more appropriate. Wrap the request instantiation in an eval (with shim), so that we can throw an error on deserialization failure. By throwing an error in this way, we can send a serialized response (another small win) rather than the plain text 500 error. PLUS .. one can use the existing core.error.* hooks to modify the error as needed, providing a solution to #1482.
cromedome
pushed a commit
that referenced
this issue
Apr 11, 2020
When a request that should be deserialized has bad content (such as invalid JSON), the serializer throws an error and returns undef. That gets caught and request object creation dies, which is then handled in the App's psgi sub resulting in a 500 error. When deserialisation fails, one typically does NOT want the client repeating the request, in which case a 400 Bad Request error would be more appropriate. Wrap the request instantiation in an eval (with shim), so that we can throw an error on deserialization failure. By throwing an error in this way, we can send a serialized response (another small win) rather than the plain text 500 error. PLUS .. one can use the existing core.error.* hooks to modify the error as needed, providing a solution to #1482.
|
Thanks again for reporting the issue @seav. The work in #1509 has been merged into master in preparation for a new release (April 2020); deserialization failure will throw a 400 Bad Request. There's an example in the test suite (see |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, if Dancer2 fails to deserialize a request body, it throws an error and returns an HTTP 500 error response. I think it would be better if we can distinguish failure due to user input (e.g.,
Content-Type: application/jsonbut the JSON is invalid) for which we should return a HTTP 4xx error (most likely 400 Bad Request), and due to internal server errors (maybe a Perl module is missing) for which HTTP 500 is the correct response.I am not sure how this issue is affected by #1056.
The text was updated successfully, but these errors were encountered: