1454995 - Filenames in "Content-disposition" header are not decoded

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Rafal P.]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

When opening an URL to a file, if the server sends it with a 'Content-Disposition: attachment; filename="encoded%20name.ext"', the file name is not decoded. Simplest way to reproduce (using netcat from the Ubuntu 16.04 netcat-openbsd package):
- in your shell run: `echo -e 'HTTP/1.1 200 OK\nContent-Disposition: attachment; filename="%C5%BC%C3%B3%C5%82w.txt"\n\nTest content' | nc -l localhost 1500`
- visit http://localhost:1500/ in Firefox


Actual results:

Firefox saves / opens the file as '%C5%BC%C3%B3%C5%82w.txt'


Expected results:

File should be saved / opened as 'żółw.txt'

Comment 1

[Boris Zbarsky [:bzbarsky]]

When I follow those steps to reproduce, I get no save/open behavior, in either Chrome or Firefox...

Anyway, the relevant question here is whether the filename parameter should be %-decoded and if so what encoding should be assumed for the resulting bytes.  The relevant specs are https://tools.ietf.org/html/rfc5987#section-3.2 and maybe https://tools.ietf.org/html/rfc2047

Looks to me like the answers are "maybe" and "it's complicated".  This particular header is not actually sending charset information, so it's not clear to me that it even matches the "this is a non-ASCII string" BNF cases from those RFCs.  Julian, you've looked into this stuff in the past; do you recall what the right behavior here is offhand?

Comment 2

[Julian Reschke]

The RFCs do not define percent-encoding *unless* the parameter uses the "*" syntax defined in <https://greenbytes.de/tech/webdav/rfc6266.html#header.field.definition>.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Julian, thank you!