Return 400 Bad Request if request parameters cannot be decoded
What does this MR do and why?
Previously if a POST request were made with an application/json
Content-Type but the body was not JSON, the middleware that checks for
malformed parameters would encounter
ActionDispatch::Http::Parameters::ParseError
when it attempted to
access request.parameters
. This error would be caught by the Puma
low-level handler and cause a 500 error to be returned.
Instead of a 500 error, we now catch this exception and treat it as a malformed string. This results in a 400 Bad Request, which is a more appropriate response.
Relates to #427210 (closed)
Screenshots or screen recordings
How to set up and validate locally
- On
master
, run:
curl -v -X POST -H "Content-Type: application/json" -d "{ nothing }" http://gdk.example.com/api/v4/projects/12345/releases
-
You'll see a 500 error and
An error has occurred and reported in the system's low-level error handler.
as the error message. -
On this branch, you should see
400 Bad Request
.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.