Webhook Trigger for Post Requests Breaks when able to receive binary data

[shalalalaw]

Describe the bug
Webhook trigger receiving both JSON and binary data now shows the JSON params as binary data, and the JSON params themselves look empty.

To Reproduce
Steps to reproduce the behavior:

1. Webhook trigger expecting post request (binary data on)
2. Send request with both binary data and body params
3. View webhook node output (see binary contents and JSON contents)
4. Note: You might have to first do a binary post, then a JSON post and review the output of each

Expected behavior
Binary shows attached content, JSON/Schema view should hold params

Environment (please complete the following information):

• OS: Ubuntu Linux 20.04
• n8n Version 1.6.1
• Docker Compose installation

Additional context
Same exact flow worked prior to change.

[Joffcom]

Hey @shalalalaw,

Which version of n8n were you running previously? Can you also try not setting the Binary Data option, I have done a quick test and that seems to be working for me so could be a workaround for you.

[shalalalaw]

@Joffcom I'm not positive, I had tried to update about two weeks ago and ran into this issue, so I rolled it back. I can say pretty positively that it was no more than three versions back, and the flow is several months old (so it worked consistently across versions until now).

I was able to get that particular workaround in place, but I figured the bug report would be helpful anyways. Thanks.

[Joffcom]

I have created NODE-807 as our internal ticket to look into this a bit more and either fix how it works or update the documentation.

[marlom-rvvup]

Same issue, we just upgraded to n8n 1.21.1 from the latest 0.x and moved from mysql to postgres.

Will give the scenarios below but here is the source of the issue:

n8n/packages/nodes-base/nodes/Webhook/Webhook.node.ts

Lines 228 to 230 in 97aa38e

	if (files?.length) {
	returnItem.binary = {};
	}

Seems like files is never an array but an object with instances of File where the key seems to be the name given when setting Binary Property option.

When binary property is not set, makes this fail:

n8n/packages/nodes-base/nodes/Webhook/Webhook.node.ts

Line 257 in 97aa38e

returnItem.binary![binaryPropertyName] = await context.nodeHelpers.copyBinaryFile(

---

First scenario (updating the existing webhook node)

When previously it automatically was detecting the binary file and doing the right thing, after the upgrade it started saying:

TypeError: Cannot set properties of undefined (setting 'file')
    at Webhook.handleFormData (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Webhook/Webhook.node.js:210:55)
    at Object.executeWebhook (/usr/local/lib/node_modules/n8n/dist/WebhookHelpers.js:215:33)

Had to change the Webhook node (typeVersion: 1) to this:

Step 1 is required to "add property" start showing the 2 so I can say "file" is the binary field.
Once that is done, the webhook node doesn't fail anymore but presents the problem raised here where the content of the file is:

------WebKitFormBoundary933lJZ9SFwdcrANv
Content-Disposition: form-data; name="file"; filename="my-test-file.jpg"
Content-Type: image/jpeg

...BINARY DATA HERE....

------WebKitFormBoundary933lJZ9SFwdcrANv
Content-Disposition: form-data; name="type"

avatar
------WebKitFormBoundary933lJZ9SFwdcrANv--

By the look of it seems like instead of parsing the formdata, it is saving the entire body as binary for file.

Second scenario (deleting Webhook node and adding a new one)

After removing and adding again the webhook node Binary Data was not showing at all and I was able to set Binary Property directly.

Now the error gets similar to the initial one:

TypeError: Cannot set properties of undefined (setting 'file0')
    at Webhook.handleFormData (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Webhook/Webhook.node.js:210:55)
    at Object.executeWebhook (/usr/local/lib/node_modules/n8n/dist/WebhookHelpers.js:215:33)

Here It fails in the same place, but it looks like it tries to set file0 when the name I gave was just file.

Workflow test

{
  "name": "My workflow",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "test",
        "responseMode": "responseNode",
        "options": {
          "binaryPropertyName": "file"
        }
      },
      "id": "e0a8eeb0-2e34-4dc2-a156-ac4282be7754",
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1.1,
      "position": [
        1060,
        660
      ],
      "webhookId": "19c4d395-8f3d-4f6a-9478-d02669097674"
    },
    {
      "parameters": {
        "options": {}
      },
      "id": "396b7404-2078-4ed7-9c21-890b5ca7f791",
      "name": "Edit Fields",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.2,
      "position": [
        1240,
        660
      ]
    },
    {
      "parameters": {
        "options": {}
      },
      "id": "27834575-5651-4cef-bca1-2bb0af2fb722",
      "name": "Respond to Webhook",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1,
      "position": [
        1420,
        660
      ]
    }
  ],
  "pinData": {},
  "connections": {
    "Webhook": {
      "main": [
        [
          {
            "node": "Edit Fields",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Edit Fields": {
      "main": [
        [
          {
            "node": "Respond to Webhook",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "active": false,
  "settings": {
    "executionOrder": "v1"
  },
  "versionId": "13ede9af-668d-428b-a8ab-b52a20fd9a1a",
  "id": "akOYRmJsk1Io7yKs",
  "meta": {
    "instanceId": "4a76d51d29a71c5b99488f8a7cce39b7774a5946d79d1bf7ecaf14e675bdeaed"
  },
  "tags": []
}
```

[Joffcom]

Hey,

So it looks like this was resolved in #7804 which was released in 1.21.0 so we believe the original reported issue to be solved.

There was another issue that has been solved since then which resulted in filenames having file0 so both issues here should be solved with an update.

I am going to mark this as closed and if the original issue is still a problem let me know and we can open this again.