Skip to content

Return 400 Bad Request if request parameters cannot be decoded

Stan Hu requested to merge sh-handle-parse-errors into master

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

  1. On master, run:
curl -v -X POST -H "Content-Type: application/json" -d "{ nothing }" http://gdk.example.com/api/v4/projects/12345/releases

  1. 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.

  2. 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.

Edited by Stan Hu

Merge request reports