206788 - Content-Disposition: filename=... encoding seems incorrect

Status: RESOLVED DUPLICATE of bug 162765

(Core :: Networking: HTTP, defect)

Description

[Craig Davison]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

According to RFC2183, which defines the Content-disposition header, the
filename= part of the header should be encoded as follows:
filename-parm := "filename" "=" value

Where 'value' is defined in RFC2045 as:
value := token / quoted-string

Where 'quoted-string' is defined in RFC822 as:
quoted-string = <"> *(qtext/quoted-pair) <">
qtext =  <any CHAR excepting <">, "\" & CR, and including linear-white-space>
quoted-pair =  "\" CHAR

And you can quote any CHAR.
It seems that Mozilla 1.3 and 1.4b are not following these guidelines when
interpreting a Content-dispositon: header in a response.

If I write some CGI that generates
Content-dispositon: filename="\m\y\f\i\l\e"
Content-type: text/html

testing 123

And I link to it and Save As... the link, the filename that Mozilla suggests is
_m_y_f_i_l_e, not myfile as it should.

Also, a filename="hello; there"
will result in a suggested filename
hello
As well, filename=should "be" invalid
will result in a suggested filename
should 'be' invalid

Clearly a completely different encoding scheme is being used here. Am I reading
the wrong RFC? Is Mozilla attempting to preserve compatibility with Netscape 4
behaviour? (I have no idea how Netscape 4 treats this header). Internet Explorer
actually uses URL encoding for this header, so

Content-disposition: filename="hello%20there"
will result in
hello there
under IE, but
hello%20there
in Mozilla.

I think this is a case where both browsers are wrong, but I could just be
looking at the wrong RFC...
Thanks


Reproducible: Always

Steps to Reproduce:
1. Browser receives response from server with Content-Disposition: filename=...
header

Actual Results:  
Browser decodes filename part incorrectly

Expected Results:  
Decode filename part in accordance with RFC2183, 2045, 822

Comment 1

[Craig Davison]

Anyone home?

Comment 2

[Craig Davison]

Is anyone going to respond to this? I'd like a clear idea of your encoding model
for this header.

Comment 3

[Darin Fisher]

i think this bug might be fixed in more recent nightly builds... jshin should be
able to confirm.

Comment 4

[Jon Stevens]

*** Bug 216790 has been marked as a duplicate of this bug. ***

Comment 5

[Jon Stevens]

bug #216790 notes that this is also a problem in fairly recent builds of Camino

Comment 6

[Chris Casciano]

Going to confirm after checking for dupes and testing locally (sorry, I'm moving
some boxes and can't post a stable-ly located testcase for a few days)

Grabbed the test script from bug 216790 - which only tested the space issue

Tested camino 2003081810 & Moz 20030819/os x/cvs and both behaved similarly
although Camino automatically downloads where moz prompts first.

The following created a file named simply "foo"
Test 1. header("Content-Disposition: filename=foo contract.txt");
Test 2. header("Content-Disposition: Content-Disposition: attachment;
filename=foo contract.txt");

The following worked to get a properly named file from Mozilla
Test 3. header("Content-Disposition: filename=\"foo contract.txt\"");
Test 4. header("Content-Disposition: Content-Disposition: attachment;
filename=\"foo contract.txt\"");

I didn't test the PC side, but for reference Safari 1.0 seems to name the file
'foo contract.txt' in all 4 cases, but IE5.2.3/Mac named the first ok, but the
latter 3 all with their php file name.


A more complete 'test suite' should probably be found/created to test other
parsing/compliance aspects of this bug.

Comment 7

[Jungshik Shin]

I just hit upon this bug by chance. Strange that I don't recall receiving a
single bug mail on this. 

As for comment #0, you also have to refer to RFC 2231
Anyway, you have a point about "hello; there" and "\m\y\f\i\n\a\m\e".  I'll
check it out.

Re comment #6, the first two cases can't work. If you want a space in the
filename, you have to quote it. 

Comment 8

[Jungshik Shin]

> Content-disposition: filename="hello%20there"
> will result in
> hello%20there in Mozilla.
> I think this is a case where both browsers are wrong, b

MS IE is wrong, but why do you think Mozilla is wrong ?  Unless RFC 2231
construct is used,
'%' doesn't have any special meaning so that it has to be treated as verbatim. 

Comment 9

[Jungshik Shin]

I realized that my patch for bug 162765 got landed only on June 12th. The patch
should fix all the cases reported in comment #0.
As I wrote, the first two cases in comment #6 are not valid bugs. To use space,
please, quote it.
Marking this as duplicate because the original bug reported in May was a dupe of
bug 162765


*** This bug has been marked as a duplicate of 162765 ***