Skip to content

Conversation

tristanrobert
Copy link
Contributor

@tristanrobert tristanrobert commented Sep 15, 2025

Context

Attachment with % in filename fails to download with n8n http request on API.

Proposed solution

On DocAPI.ts, it replaces contentdisposition(filename, {type: 'attachment'}) function with a filename*=UTF-8''encodeURIComponent(filename)
I am not sure that DocWorker is needed too.

Related issues

Has this been tested?

Yes with a n8n instance and a grist instance on docker compose.

  • 👍 yes, I added tests to the test suite
  • 💭 no, because this PR is a draft and still needs work
  • 🙅 no, because this is not relevant here
  • 🙋 no, because I need help

Screenshots / Screencasts

Copy link
Contributor

github-actions bot commented Sep 15, 2025

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@tristanrobert
Copy link
Contributor Author

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

I have read the Contributor License Agreement and (how could I?) sign it.

@tristanrobert
Copy link
Contributor Author

I have read the CLA Document and I hereby sign the CLA

github-actions bot added a commit that referenced this pull request Sep 16, 2025
@paulfitz paulfitz requested a review from Copilot September 16, 2025 16:20
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Fixes issue #1835 where attachments with % characters in filenames fail to download with n8n HTTP requests. The PR replaces the content-disposition library usage with a manual RFC 6266 compliant header construction using UTF-8 encoding.

  • Removes dependency on content-disposition library in DocWorker.ts
  • Replaces library calls with manual header construction using filename*=UTF-8''encodeURIComponent(filename) format in both DocWorker.ts and DocApi.ts

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
app/server/lib/DocWorker.ts Removes content-disposition import and replaces library usage with manual header construction
app/server/lib/DocApi.ts Replaces content-disposition library call with manual UTF-8 encoded header format

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Comment on lines 678 to +679
// Construct a content-disposition header of the form 'attachment; filename="NAME"'
.set('Content-Disposition', contentDisposition(fileName, {type: 'attachment'}))
.set('Content-Disposition', `attachment; filename*=UTF-8''${encodeURIComponent(fileName)}`)
Copy link

Copilot AI Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Content-Disposition header construction is now duplicated between DocApi.ts and DocWorker.ts. Consider extracting this logic into a shared utility function to avoid code duplication and ensure consistency.

Copilot uses AI. Check for mistakes.

@paulfitz
Copy link
Member

Thanks for this @tristanrobert. @jordigh plans to review. Btw what do you think of this part of the content disposition spec:

When both filename and filename* are present in a single header field value, filename* is preferred over filename when both are understood. It's recommended to include both for maximum compatibility

@jordigh
Copy link
Contributor

jordigh commented Sep 16, 2025

I would echo the implicit suggestion to use both filename and filename*, obviously removing non-ASCII characters for the former. If we can handle another dependency, this or this looks useful for the filename field, otherwise a simple, generic download.ext or similar would do.

@tristanrobert
Copy link
Contributor Author

tristanrobert commented Oct 6, 2025

I would echo the implicit suggestion to use both filename and filename*, obviously removing non-ASCII characters for the former. If we can handle another dependency, this or this looks useful for the filename field, otherwise a simple, generic download.ext or similar would do.

these two librairies have not been updated since 3 years ago. A simple replace with a regex could do the job:

filename = filename.replace(/[^\x20-\x7E]/g, '');

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants