Bug: Content-Disposition Header Lacking "filename" When "filename*" Is Present
See original GitHub issueDescription:
When sending files to a server that does not understand “filename*” parameters inside the Content-Disposition header, the server will fail to find the file name because the “filename” parameter is not also included.
Justification:
According to RFC 6266, ideal header generators will include both a “filename” and a “filename*” parameter whenever the “filename*” form is required:
– Include a “filename*” parameter where the desired filename cannot be expressed faithfully using the “filename” form. Note that legacy user agents will not process this, and will fall back to using the “filename” parameter’s content.
– When a “filename*” parameter is sent, to also generate a “filename” parameter as a fallback for user agents that do not support the “filename*” form, if possible. This can be done by substituting characters with US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by “ae”). Note that this may not be possible in some locales.
– When a “filename” parameter is included as a fallback (as per above), “filename” should occur first, due to parsing problems in some existing implementations.
Why I Care:
This inconsistency caused a many-hour debugging session when trying to discover why file uploads to Google AppEngine blobstore stopped working when the requests library was upgraded (which bundles urllib3 with install). The eventual resolution was to urlencode the file name to a str
before upload so that the “filename*” parameter was not added.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:11 (10 by maintainers)
I’m working on this.
Started doing some research. Created a Werkzeug application to echo the submitted
Content-Disposition
header.When a file named “basic.txt” is submitted from Firefox or Chromium, it prints:
When a file named “ski ⛷.txt” is submitted from Firefox or Chromium, it prints:
Browsers are providing one filename, and do not escape non-ASCII characters.