Request instantiation fails throw 400 Bad Response #1509
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This permits before error hooks to modify the error message before its rendered. Includes test/example where deserialization failure returns custom error code.
There's a grey area here between throwing a 400 Bad Request, and 500 Internal Error. As re-sending a failed request at this point is always going to fail, send this as a 400 response; so the client doesn't try again. This is a change in behaviour in core; we always sent this as a 500 error before. However issues #1496, #1507 and #1056 point to a 400 error being the better option.
|
👍 this is a clear improvement over current 500 response. I can also live with the status and message attributes switching to |
|
👍 Sorry for not approving this sooner - I was ready to but had to think through any consequences to changing the status of those attributes, then promptly dropped the ball. This is a solid fix. Thank you! |
|
Merged, thank you! |
This was referenced Apr 13, 2020
This was referenced Apr 20, 2020
cromedome
added a commit
that referenced
this pull request
May 27, 2020
[ BUG FIXES ]
* GH #1509: Request instantiation fails throw 400 Bad Response (Russell
@veryrusty Jenkins). This resolves GH #1056, 1482, 1496, 1507, 1508,
and 1510.
[ ENHANCEMENTS ]
* GH #1510: Test for proper multi-part form handing (ice-lenor, Sawyer X)
* GH #1547: Cookie SameSite support (Russell @veryrusty Jenkins)
[ DOCUMENTATION ]
* None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This started out as a patch for 1056; permitting deserialisation fails to use before hooks to alter the error thrown.
Since then, issues like #1496 and #1507 highlight that we want something more general in this regard. This PR changes behaviour, as what was previously a 500 Internal Server error when request object creation failed is now a 400 Bad Response error in line with the above issues.
Putting this out here for feedback and seeing if this is how we'd like to solve this.