Upgrade content-disposition

[blakeembrey]

Version 2 upgrade will mostly only be relevant for users that want to generate non-ASCII by ISO-8859-1 valid filenames. There was a gap in theoretical vs real behavior of browsers that sniffed this and failed to have the correct encoding for filenames because it treated them as UTF-8 instead. See jshttp/content-disposition#27 for more information.

Separately, the API no longer attempts to basename inputs so I need to do that in the Express API instead.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​content-disposition@​2.0.1

View full report

[blakeembrey]

The correct backward compatibility would be basename(name || path), should I do that instead? The difference is if someone gave a path instead of a filename in the filename parameter.

[bjohansebas]

Content-Disposition: old (v1.1.0) vs new (v2.0.1)

Express output for the tests added in test/res.attachment.js. All outputs are
RFC 6266 / 8187 / 9110 compliant.

Express call	Old (v1.1.0)	New (v2.0.1)	Changed?
res.attachment('/path/to/my report.png')	attachment; filename="my report.png"	attachment; filename="my report.png"	No
res.attachment('/locales/café.txt')	attachment; filename="café.txt"	attachment; filename="caf?.txt"; filename*=UTF-8''caf%C3%A9.txt	Yes
res.attachment('')	attachment; filename*=UTF-8''	attachment; filename=""	Yes

Notes

• Space in name: still quoted in both, a non-token value must be a quoted-string.
• Latin1 name: v2 emits an ASCII fallback (filename) plus the UTF-8 filename*
  extended form, instead of putting the raw non-ASCII byte in filename — more
  interoperable and spec-clean.
• Empty name: both valid; v2 uses an empty quoted-string, v1 an empty filename*.