205232 - failed to reassemble encoded multi-byte filename in HTTP "Content-disposition" header

Status: RESOLVED DUPLICATE of bug 162765

(Core Graveyard :: File Handling, defect)

Description

[alpha2_valen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.3.1) Gecko/20030425

Given this piece of JSP code:
----8x----
<%
response.setHeader("Content-type", "audio/mp3;charset=UTF-8");
response.setHeader("Content-disposition",
"inline;filename=%E8%BB%8A%E5%A9%89%E5%A9%89%20-%20%E4%B8%8D%E5%BF%85%E5%89%8E%E6%8E%A3.mp3");
%>
----8x----

When the dialog pops up, the file name still remain the crumbled characters above.

This code, however, will work with Internet Explorer 5.5.

I know Content-disposition is not a part of standard HTTP, but I do need this.

Reproducible: Always

Steps to Reproduce:
1. Cut the code above and save as foobar.jsp
2. Deploy the jsp to Tomcat-4.1.24
3. Start Tomcat
4. Access foobar.jsp
5. file dialog pops up, and crumbled filename displays at file dialog


Expected Results:  
The file dialog should have the correct filename displayed instead of the
encoded filename.

Comment 1

[alpha2_valen]

Attachment: The JSP source code

Attention: this files does not contain binary data that would be able to
produce copyrighted music files, i.e., mp3 files.

Comment 2

[alpha2_valen]

Attachment: The file dialog shown to client when the JSP is invoked

Comment 3

[alpha2_valen]

Attachment: What the file dialog should show (taken from IE 5.5)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Content-Disposition is defined to be ASCII in early drafts of the relevant spec.
 Later drafts specify the encoding format for that header -- see 162765.

What you're doing (using the "charset" parameter to the "content-type" header to
affect the processing of the "content-disposition" header) is definitely not
something that should be working in theory...

In practice, Jungshik, do we want to make this work?  Should be pretty easy....

Comment 5

[alpha2_valen]

Attachment: The JSP source, without the charset in header, that will produce the same result

Attention: this file does not contain binary data that would be able to produce
copyrighted mp3 files.

Comment 6

[Jungshik Shin]

This is simply a dupe of bug 162765. When it's resolved, so will this one. I'm
gonna mark this
as dupe.

As bz wrote, 'charset' specified in C-T header (especially for 
non-textual type) in http-header has NOTHING to do with charset used
in other header fields. Even when it's specified for textual type(text/*),
it's not for the other header fields but for the message **body** only. 

In attachment 122948 [details], the value of 'filename' parameter is in UTF-8 (url-escaped)
so that it doesn't matter because Mozilla tries UTF-8 anyway. However, the
following 
wouldn't work even with my current patch _unless_ the current locale is Japanese
that uses
EUC-JP as the codeset:

Content-Type: application/pdf; charset=EUC-JP
Content-Disposition: attachment; filename=%B0%A1%B0%A2.pdf

In practice, it's pretty easy to honor this non-standard-practice
as bz pointed out. Simply checking the value of charset parameter of C-T header 
and specifying it as 'aFallbackCharset' when invoking
nsMIMEHeaderParam->GetParameter
in ext-handler  would do it. However, I'm not sure whether Mozilla has to be
this much generous considering that it's not that difficult to emit

Content-Type: application/pdf
Content-Disposition: attachment; filename*EUC-JP''=%B0%A1%B0%A2.pdf

instead of the above. 

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