144995 - File Save dialog box doesn't show proper Korean char on Sol2.8 ( Kor locale) in Netscape 4.7 and above browsers.

Status: VERIFIED WONTFIX

(Core :: Internationalization, defect)

Description

[Saumyabrata Bandyopadhyay]

Test case :
The jsp file is given below .
<%@ page contentType="application/vnd.ms-excel" %>
<%@ page session="false" %>
<%!        
public static String iso8859(String str) 
{           
        if (str == null)    
        { 
                return  str; 
        }                
        
        try 
        { 
                str = new String(str.getBytes("KSC5601"), "8859_1");             
   
        } 
        catch (Exception e) { System.err.println(e.toString()); }                
        
        return  str; 
}
%>
<%
String fileName ="ÇѱÛ.xls";
response.setHeader("Content-Disposition", "attachment; filename=" + fileName + 
";");
%>
ºÐ±â    1       2       3       4
¼­¿ï    1       3       5       7
´ëÀü    7       8       9       0
´ë±¸    0       0       8       9
ºÎ»ê    9       0       8       6


This is working perfectly fine with Win2K.

WebServer response :
IE on Win2k (Korean locale):
---------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:37:51 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Transfer-Encoding: chunked

b9

ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6


0

Netscape6.2.2 on Solaris(Korean)
-----------------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:43:42 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Connection: close


ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6



Netscape4.76 on Win2k(Korean)
---------------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:47:30 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Connection: close



ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6

Comment 1

[Matthias Versen [:Matti]]

What do you mean with "Netscape 4.7 and above browsers." ?
This is a mozilla bug database. Do you see this with Mozilla RC2 or later ?

Comment 2

[Saumyabrata Bandyopadhyay]

This bug is reproducible in Netscape6.2.2. It seems that is the snapshot of 
Mozilla. 
Anyway I filed a bug against netscape 6.x , but it doesn't give me any bug id to 
track .

Comment 3

[Matthias Versen [:Matti]]

Ns6.2.2 is old (based on Mozilla0.9.4) 

-> Int for a look

Comment 4

[Yuying Long]

cc some experts: Katakai for Sun, Junkshik Shin for Korean.

Could any of you please help confirm this? thanks!

Comment 5

[Jungshik Shin]

It's not allowed to use non-US-ASCII character in filename
parameter of Content-Disposition field. What you're transmitting
is violating the MIME standard. You should properly encode
filename parameter in non-US-ASCII according to RFC 2231.
(http://www.faqs.org/rfcs/rfc2231.html)

IMHO,  MS IE is overly generous in this respect. 

I believe Mozilla (RC2) is able to handle RFC 2231-encoded 
filename parameters of Content-Disposition header fields.

In light of this, I think this should be marked as "won't fix". 

Comment 6

[Jungshik Shin]

  The properly encoded http header should look like the following

Content-disposition: attachment; 
   filename*=euc-kr'%C7%D1%B1%DB.xls

or

Content-dispositon: attachment;
    filename*=UTF-8'%ED%95%9C%EA%B8%80.xls

Comment 7

[Saumyabrata Bandyopadhyay]

Then how come it is working with netscape 4.7x on Win2K.

Comment 8

[Jungshik Shin]

That does NOT mean  that what you're doing is compliant to
MIME/HTTP standard. That does ONLY mean that NS 4.7x was just as lazy
(or overindulgent) as MS IE in not properly checking the value of the
filename parameter(and  condoning your and many others' mistakes).  As you
should be able to see by reading RFC's, using non-US-ASCII chars. in
filename parameter is not allowed.  You should NOT rely on browsers'
generousity/overindulgence when writing server-side applications.

  Moreover, what you're doing does NOT work even with MS IE(and
NS 4.7x) unless your clients set their locale to Korean with the
encoding set to EUC-KR or CP949. I don't use ko_KR.EUC-KR any more,
but use ko_KR.UTF-8 locale. Even if Mozilla is modified to behave as
you requested, it would not work for me, let alone many
other users who use non-Korean locales.

  If you make your server-side application compliant to MIME/HTTP
standard, it would work regardless of what locale your clients
use as long as they use multilinugal OS' like Win2k and Unix(-like)
OS under UTF-8 locale. (of course, it would also work under Korean
locale with the encoding set to EUC-KR or CP949.)

Comment 9

[Yuying Long]

Mark as won't fix according to Junk-Shik Shin's comments.

Please re-open if disagree.

Comment 10

[Yuying Long]

Verified.