Azure Functions (node) doesn't process binary data properly

[christian-vorhemus]

UPDATE: Per final design, we added a property request.bufferBody that you can use to access the binary data

---

My goal is to write a function which processes the binary HTTP body (for example, an image). I've created the function using the func CLI (version 2.7.2254) doing the following:

func init --worker-runtime "node" --language "typescript"
func new --name "SampleFunction" --template "HTTP trigger"
npm install
npm install @types/node --save

My function.json looks like this:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "dataType": "binary",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ],
  "scriptFile": "../dist/SampleFunction/index.js"
}

My expectation would be that now req.body is a Buffer but when I check the type
typeof req.body;

it seems to be a string. Therefore, my attempt to save this file to disk like you see below in my index.ts also fails:

import { AzureFunction, Context, HttpRequest } from "@azure/functions"
const fs = require('fs');

const httpTrigger: AzureFunction = async function (context: Context, req: HttpRequest): Promise<void> {
    context.log('HTTP trigger function processed a request.');
    var file = req.body;
    fs.writeFileSync("file.png", file, 'binary');
};

export default httpTrigger;

Test:

curl -X POST --data-binary "@C:\path\to\image.png" http://localhost:7
071/api/SampleHttpFunction

What's the correct way of processing binary data in a node based Azure Function?

[yojagad]

Can you try this with the Content-Type set to "application/octet-stream" ?

[christian-vorhemus]

Indeed, if the content type is set to "application/octet-stream" it works.

But why does it fail when Content-Type is more specific, for example "image/png"? "application/octet-stream" isn't telling the web app anything other than it is some binary data. If req.headers looks like this, it fails:

{
  "cache-control": "no-cache",
  "connection": "keep-alive",
  "content-type": "image/png",
  "accept": "*/*",
  "accept-encoding": "gzip, deflate, br",
  "authorization": "Bearer U0V3Q",
  "host": "localhost:7071",
  "user-agent": "PostmanRuntime/7.24.0",
  "content-length": "11460",
  "postman-token": "897aaa99-f0c5-40fb-80db-3d7b24a01572"
}

Or is the function host logic simply saying: If content type equals "application/octet-stream" treat HTTP body as binary file, otherwise as string?

[yojagad]

Yeah, there's specific logic around content-type "application/octet-stream" and those starting with "multipart" (https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/Extensions/HttpRequestExtensions.cs).

I'll go ahead and close this thread since this solved the issue. Please feel free to reopen/start new thread if you have any more questions around this.

[christian-vorhemus]

Alright, then just out of interest, is this behavior documented somewhere? Because I'd assume this can be a potential pitfall for users who send data to an Azure Function by a browser (at least the browsers I've seen will by default set the Content-Type header based on the actual file type and not only to "application/octet-stream") or use e.g. Postman for testing.

And why do we set "dataType": "binary" in the function.json when apparently the Content-Type header decides how the HTTP body is treated?

[yojagad]

Tagging @mhoeger and @pragnagopa who might have answers to this.

[pragnagopa]

reopening and moving to nodejs worker repo to provide a code sample.
Using isRaw flag: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#response-object should provide data as buffer. @mhoeger can you confirm?

[mhoeger]

"isRaw" is about the response but not the request. I also need to double check if that guidance is now deprecated, because "isRaw" was a V1 feature.

The "dataType" property is applied by some bindings, but isn't for the HttpBinding, which is misleading :\ agreed that we should document which ones we special-case to send as binary.