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
Is anyone going to respond to this? I'd like a clear idea of your encoding model for this header.
Severity: normal → major
i think this bug might be fixed in more recent nightly builds... jshin should be able to confirm.
*** Bug 216790 has been marked as a duplicate of this bug. ***
bug #216790 notes that this is also a problem in fairly recent builds of Camino
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
> 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.
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 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.