293540 - url-escaped content-disposition filename not converted

Status: RESOLVED WONTFIX

(Core Graveyard :: File Handling, defect)

Description

[Jamie Thompson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

When an default filename is speciifed by content-disposition and is url-encoded
(i.e. "a test.txt" -> "a%20test.txt") it is not unescaped in the file picker
dialog. I suspect this falls under the undefined UA filename conversion
provision of RFC2183, but it seems a fairly harmless but logical course of
action to take.

Reproducible: Always

Steps to Reproduce:
1. Click "save link as" on a download that has an escaped content-disposition header
2. Note that the filename has not been converted
3.

Actual Results:  
file picker contains unescaped default filename i.e. "a%20test.txt"

Expected Results:  
file picker should contain unescaped filename i.e. "a test.txt"

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm pretty sure that urlencoding is the wrong way to escape characters here...

Comment 2

[Jamie Thompson]

Unfortunately, the RFC I read was somewhat sparse in this regard. IE seems to
handle it, and the way I noticed this behaviour was due to me forgetting to trim
the leading '/' from the filename passed as the content-disposition. Firefox
wouldn't display it correctly unless it was unescaped but quoted and IE wouldn't
display it correctly unless it was urlencoded.

The catch-22 was only beaten when I noticed the leading '/' being passed in.
Removing this allows IE to handle the filename quoted, but it struck me that
urlencoding would also allow more estoric characters, though prehaps that would
best be handled by sending utf8 headers instead.

All in all, it was just a thought as I managed to resolve my quandry.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Non-ascii chars in content-disposition are allowed by updates to the MIME RFC's
that allow indicating a character encoding for a header.  No need for URL-escaping.

The problem with URL-escaping is that "%ff" is a perfectly valid filename and we
shouldn't be munging it to "f" just because we feel like it....