Changed behavior in function body encoding

Hey all,
We are making a breaking change on August 28, 2020 to how we handle the function body that could impact you if you:

The bug

We currently determine whether to base64 encode the function request body based on whether the content-type header starts with text/ or application/. In both of these cases, we do not encode the body. This means that if you send a binary media type like application/octet-stream through a Netlify Function, it will be treated as plain text and garbled in the process.

The fix

Going forward, we will base64 encode the body if the content-type starts with application/. This will ensure that binary media types like application/octet-stream and application/pdf arrive at their final destinations intact.

Exceptions

Requests with the following content-types will not be base64 encoded, even though they start with application/:

  • application/json or application/*+json
  • application/xml or application/*+xml
  • application/javascript
  • application/csp-report
  • application/graphql
  • application/x-www-form-urlencoded
  • application/x-ndjson

What you can do

  • Make sure that your content-type: application/* headers reflect the encoding you want for your function body
  • Make sure your code respects the isBase64Encoded parameter

Ask us for help!

Please feel free to reach out with questions and we will do our best to answer.


Many thanks to @bennadel for bringing this bug to our attention and doing incredible investigation work in this thread: Baffled by Binary event.body in Lambda Function :slight_smile:

5 Likes

If anyone is curious, here’s what I was trying to do - proxy S3 pre-signed URL uploads through a Netlify Function - http://bjam.in/s3-netlify-proxy . The thing we use to upload the files is always sending application/octet-stream (which we don’t really have control over). And, this was getting confused in the Netlify Function. But, now that this is fixed, my experiment works!

1 Like