Binary data not receiving proper metadata

Questions
1

Hi all,

I’ve got a flow running successfully since a few years, but since December, this step doesn’t work anymore: I’m downloading files, and then check on the file extension. This used to work properly, but since December, it seems that reading out this file isn’t possible anymore: the file is downloaded, but both the extension as the filename are not added to the file as it used to do.

As you can see, the filenames & content types are correctly gathered per file:

image
image1920×1510 125 KB

But the filenames & extensions are not added:

image
image1012×2390 150 KB

In another step in the flow, I used to Decompress the zip files. This also doesn’t work anymore:

image
image4528×1092 237 KB

No clue what has been changed as this flow used to work perfectly before December :face_with_raised_eyebrow:

Thanks in advance!!

(I’m using v1.25.1 via Docker installation on Ubuntu)

2

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
3

It seems something related to files from a specific domain.

This is a test flow to isolate the issue I have.

Any file of this domain (https://www.sdworx.com) is providing me this issue. If I replace the URL of the file with another URL (eg https://www.wto.org/english/thewto_e/procurement_e/terms_conditions_e.pdf), it works as it should.

Does anyone know why this happens to this domain?

Thanks!!

5

Hi @Cadish, thanks so much for reporting this (and especially for providing the example workflow!) and sorry for the trouble.

It appears the server at sdworx.com is not sending the content-disposition header from your original screenshot which is used by n8n to identify the file name:

image
image1920×1510 123 KB

Of course, n8n should still be able to use the filename based on the URL, which doesn’t seem to be happening here, so I think you’ve unfortunately encountered a bug :frowning:

I’ll add this to our engineering backlog for further investigation and fix, and we’ll update this thread as soon as a fix is available.

7

Great! Thanks a lot for your reply.

Looking forward to a fix.

8

New version n8n@1.29.0 got released which includes the GitHub PR 8583.

9

Great! Thanks a lot @jan!