7.92 KB, image/png
7.34 KB, image/png
198 bytes, text/plain
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.
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.
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....
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
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Component: Networking: HTTP → File Handling
QA Contact: httpqa → cpetersen0953
You need to log in before you can comment on or make changes to this bug.