# Function seems to be receiving malformed binary request data

**URL:** <https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713>\
**Category:** Support\
**Tags:** lambda-functions\
**Created:** [November 3, 2021, 4:18pm UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713 "2021-11-03T16:18:24Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Xenonym](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/xenonym/32/31035_2.png) [@Xenonym](https://answers.netlify.com/u/Xenonym)\
**Post date:** [November 3, 2021, 4:18pm UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/1 "2021-11-03T16:18:24Z")

</div>

**Site name** : [https://infallible-elion-0e4df6.netlify.app](https://infallible-elion-0e4df6.netlify.app)  
**Repository** : [https://github.com/Xenonym/netlify-binary-reprod](https://github.com/Xenonym/netlify-binary-reprod)

The site is a simple reproduction of an issue I am facing with sending requests with binary data to a Netlify function.

When you click _Test_, the site will send a fetch request with binary data to a Netlify function:

```plaintext
// As Base64: AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE=
const data = new Uint8Array([
  0, 0, 1, 0, 0, 1, 0, 0, 0, 0,
  0, 0, 7, 101, 120, 97, 109, 112, 108, 101,
  3, 99, 111, 109, 0, 0, 1, 0, 1
]);
async function reflect(contentType) {
  const response = await fetch('/.netlify/functions/reflect', {
    method: "POST",
      headers: {
        "Content-Type": contentType,
        "Content-Length": data.length
      },
      body: data
  });
  return response.text();
}

```

(The binary data is a DNS packet for an A query for [example.com](http://example.com).)

The Netlify function simply returns whatever was sent to it:

```plaintext
export async function handler({ body }) {
  return {
    statusCode: 200,
    body,
  };
}

```

This function _should_ return identical data from what is being passed in. However, when deployed, the function seems to receive malformed data:

Sent: `AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE=`  
Recieved: `AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAAB`

The data received by the function is missing the last two bytes, which can also be observed from the Base64 encoded version ending with `AB` instead of the original `AE=`.

This happens both when using the `Content-Type` for DNS packets (`application/dns-message`) or for generic binary data (`application/octet-stream`).

Is this a bug with handling binary data in Netlify functions? Given that the function above does not do anything apart from what is being sent in, I am confused as to why the binary data received by the function is different from the one being sent by the client.

---

<div class="post-metadata">

**Author:** ![hrishikesh](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/hrishikesh/32/74607_2.png) [@hrishikesh](https://answers.netlify.com/u/hrishikesh)\
**Post date:** [November 3, 2021, 4:45pm UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/2 "2021-11-03T16:45:14Z")

</div>

Your function needs to be:

```auto
export async function handler({body}) {
  return {
    statusCode: 200,
    body: Buffer.from(body, 'base64').toString('utf8')
  };
}

```

Because of:

> [@Changed behavior in function body encoding](https://answers.netlify.com/t/changed-behavior-in-function-body-encoding/19000):
>
> 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: Use content-type: application/\* headers in your POST or PUT requests to Netlify Functions Don’t check the function body’s isBase64Encoded parameter, described in our docs here: [Build functions | Netlify Docs](https://docs.netlify.com/functions/build-with-javascript/#format) 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 …

Demo: [https://quirky-mirzakhani-33e90a.netlify.app/](https://quirky-mirzakhani-33e90a.netlify.app/)

Note that, the above would return the decoded string so `example com` in your case.

---

<div class="post-metadata">

**Author:** ![Xenonym](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/xenonym/32/31035_2.png) [@Xenonym](https://answers.netlify.com/u/Xenonym)\
**Post date:** [November 4, 2021, 5:15am UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/3 "2021-11-04T05:15:20Z")

</div>

Thanks for the reply @hrishikesh! However, the binary data is not a string, so comparing the sent and received data interpreted as UTF-8 may be misleading, since most of the bytes in the data are not actually UTF-8, apart from the domain name.

In your reprod site ([https://quirky-mirzakhani-33e90a.netlify.app/](https://quirky-mirzakhani-33e90a.netlify.app/)), we can actually see that the `Content-Length` being sent and received is different, and the data receieved is shorter than what was sent by two bytes:

 ![firefox_mcwsvFoSpD](https://global.discourse-cdn.com/netlify/original/3X/4/e/4e26f444990efb13bb166fbc6c7eb3ed60cf85fd.png)

Assuming that the `reflect` function is largely the same, I am still not sure why the last two bytes will get lost when received by the function handler, especially when the function does nothing but return what was sent.

P.S. I note that for some reason the response is being returned with a `Content-Type` of `image/x-icon`, which was not set by the function handler in the first place.

---

<div class="post-metadata">

**Author:** ![hrishikesh](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/hrishikesh/32/74607_2.png) [@hrishikesh](https://answers.netlify.com/u/hrishikesh)\
**Post date:** [November 4, 2021, 11:15am UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/4 "2021-11-04T11:15:48Z")

</div>

Well okay, I now return the data as `Uint8Array` and see the problem better, here are the 2 arrays:

```auto
[0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 7, 101, 120, 97, 109, 112, 108, 101, 3, 99, 111, 109, 0, 0, 1, 0, 1] // sent
[0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 7, 101, 120, 97, 109, 112, 108, 101, 3, 99, 111, 109, 0, 0, 1] // received

```

So the `0, 1` from the end seem to be missing. It seems to be an extra space that’s lost.

However, have you tried this with real files? I’ve used the similar method for files and it seems to work fine.

Do you have a more complex example where the problem is more prominent?

---

<div class="post-metadata">

**Author:** ![Xenonym](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/xenonym/32/31035_2.png) [@Xenonym](https://answers.netlify.com/u/Xenonym)\
**Post date:** [November 5, 2021, 11:01am UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/5 "2021-11-05T11:01:57Z")

</div>

@hrishikesh

> [@hrishikesh](#):
>
> However, have you tried this with real files? I’ve used the similar method for files and it seems to work fine.

Do you mean trying to submit with a form e.g. `multipart/form-data`? I imagine that would work, since `form-data` would be encoded, but the issue with sending binary data would remain: the handler shouldn’t be missing bytes from the request in the first place.

> [@hrishikesh](#):
>
> Do you have a more complex example where the problem is more prominent?

Not too sure what you mean here, but I have updated [https://infallible-elion-0e4df6.netlify.app/](https://infallible-elion-0e4df6.netlify.app/) to take in an arbitrary size of base64 encoded data. The issue seems to replicate with 4096 bytes of random data (`crypto.randomBytes(4096).toString('base64')`) at least.

---

<div class="post-metadata">

**Author:** ![hrishikesh](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/hrishikesh/32/74607_2.png) [@hrishikesh](https://answers.netlify.com/u/hrishikesh)\
**Post date:** [November 5, 2021, 12:19pm UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/6 "2021-11-05T12:19:12Z")

</div>

> [@Xenonym](#):
>
> Do you mean trying to submit with a form e.g. `multipart/form-data` ?

No, in the past, I was able to send files to functions by base64 encoding them on the client-side and sending the data as JSON. The files were received correctly and didn’t cause any corruption.

> [@Xenonym](#):
>
> handler shouldn’t be missing bytes from the request in the first place.

I’ve filed an issue for investigation.

---

<div class="post-metadata">

**Author:** ![Xenonym](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/xenonym/32/31035_2.png) [@Xenonym](https://answers.netlify.com/u/Xenonym)\
**Post date:** [November 19, 2021, 4:41am UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/8 "2021-11-19T04:41:06Z")

</div>

Hey @hrishikesh! I was wondering if there was any update to this issue?

---

<div class="post-metadata">

**Author:** ![hrishikesh](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/hrishikesh/32/74607_2.png) [@hrishikesh](https://answers.netlify.com/u/hrishikesh)\
**Post date:** [November 19, 2021, 1:35pm UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/9 "2021-11-19T13:35:15Z")

</div>

Hey @Xenonym,

I just had a talk with the team handling Functions and looks like this is being escalated and awaiting response from another team at the moment. We’d update this thread when stuff moves around.

---

<div class="post-metadata">

**Author:** ![hrishikesh](https://sea1.discourse-cdn.com/netlify/user_avatar/answers.netlify.com/hrishikesh/32/74607_2.png) [@hrishikesh](https://answers.netlify.com/u/hrishikesh)\
**Post date:** [May 25, 2022, 10:43am UTC](https://answers.netlify.com/t/function-seems-to-be-receiving-malformed-binary-request-data/46713/11 "2022-05-25T10:43:09Z")

</div>

Hey @Xenonym,

We just wanted to let you know that a fix for this has been released and it should be working normally going forward.