Skip to content

Fix encoding for non-ASCII filenames in Content-Disposition header #58259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix encoding for non-ASCII filenames in Content-Disposition header #58259

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions lib/_http_outgoing.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -635,6 +635,19 @@ function parseUniqueHeadersOption(headers) {

return unique;
}
function maybeEncodeFilenameHeader(value) {
const filenameMatch = value.match(/filename="(.+?)"/);
Copy link
Member

Choose a reason for hiding this comment

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

If I'm reading this correctly it assumes that the value for the filename is always quoted. It's been a while since I've looked but I'm not sure if that's actually required by the relevant specs. RFC2183 where this is originally defined generally is quite careful about indicating when the value must be quoted and I don't recall anything there saying that filename must be a quoted string value.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for pointing that out, @jasnell — you're absolutely right. The current implementation incorrectly assumes that the filename value is always quoted, which isn't guaranteed per RFC 2183. According to the spec, the filename parameter can be either a quoted-string or a token, so it's valid for it to appear without quotes.

I've updated the logic to handle both quoted and unquoted filename values using a more flexible regex:

-> const filenameMatch = value.match(/filename=(?:"([^"]+)"|([^;\s]+))/);
-> const filename = filenameMatch ? (filenameMatch[1] || filenameMatch[2]) : null;

Let me know if you think we should handle any additional edge cases. Thanks again!

Copy link
Author

Choose a reason for hiding this comment

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

-> const filenameMatch = value.match(/filename=(?:"([^"]+)"|([^;\s]+))/);
-> const filename = filenameMatch ? (filenameMatch[1] || filenameMatch[2]) : null;

if (!filenameMatch) return value;

const filename = filenameMatch[1];
if (/^[\x00-\x7F]*$/.test(filename)) {
// ASCII only — no need to encode
return value;
}

const encoded = encodeURIComponent(filename);
return `attachment; filename*=UTF-8''${encoded}`;
}

OutgoingMessage.prototype.setHeader = function setHeader(name, value) {
if (this._header) {
Expand All @@ -646,6 +659,9 @@ OutgoingMessage.prototype.setHeader = function setHeader(name, value) {
let headers = this[kOutHeaders];
if (headers === null)
this[kOutHeaders] = headers = { __proto__: null };
if (name.toLowerCase() === 'content-disposition') {
value = maybeEncodeFilenameHeader(value);
}

headers[name.toLowerCase()] = [name, value];
return this;
Expand Down