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



16 years ago
2 years ago


(Reporter: alpha2_valen, Assigned: darin.moz)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(3 attachments, 1 obsolete attachment)



16 years ago
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:
response.setHeader("Content-type", "audio/mp3;charset=UTF-8");

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

16 years ago
Created attachment 122948 [details]
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

16 years ago
Created attachment 122949 [details]
The file dialog shown to client when the JSP is invoked

Comment 3

16 years ago
Created attachment 122950 [details]
What the file dialog should show (taken from IE 5.5)
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

16 years ago
Created attachment 122972 [details]
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.
Attachment #122948 - Attachment is obsolete: true

Comment 6

16 years ago
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
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
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 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE


16 years ago
Component: Networking: HTTP → File Handling
QA Contact: httpqa → cpetersen0953
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.