14667 2007-07-19 03:51:13 -0700 Discussion: form,filename, what to do about encoding of filename part with nonascii-chars 2010-09-07 03:03:14 -0700 1 1 1 Unclassified WebKit Forms 523.x (Safari 3) All All NEW P4 Enhancement --- 1 808caaa4.8ce9.9cd6c799e9f6 webkit-unassigned aestes ap danny-bugzilla ddkilzer oldest_to_newest 4336 0 808caaa4.8ce9.9cd6c799e9f6 2007-07-19 03:51:13 -0700 #Original title: "Discussion: form,filename, what to do about encoding of filename part" #Please retitle me derived from bug#14635 Origin is: With this site(webkit-buglizza), I coudn't upload file from my Desktop. After moving file to somewhere like c:\__sendtemp\, uploading succeeded. Why-full-path-is-post issue is left to bug#14635. "While "most experienced users know about the perils of non-ASCII file names," therefore many beginners who starts web with Safari/WebKit, who had not have a bitter. What we shoud do about encoding of filename part? Please read bug#14635, with some recommended-reading RFCs. ; =============== ; posts ; =============== POST http://bugs.webkit.org/attachment.cgi HTTP/1.1 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja) AppleWebKit/522.14.1+ (KHTML, like Gecko) Version/3.0.2 Safari/522.13.1 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryAAsdAAJVAApEAA5j Transfer-Encoding: Chunked ..... ------WebKitFormBoundaryAAsdAAJVAApEAA5j Content-Disposition: form-data; name="data"; filename="C:\Documents and Settings\*****\繝・せ繧ｯ繝医ャ繝予test.html.png" Content-Type: image/png ; =============== ; response ; =============== HTTP/1.1 411 Length Required Server: Apache/1.3.33 (Darwin) PHP/4.4.1 mod_ssl/2.8.24 OpenSSL/0.9.7i DAV/1.0.3 Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 71204 1 webkit 2008-02-20 03:32:19 -0800 P5 is not used for WebKit bugs. [http://webkit.org/quality/bugpriorities.html] 273694 2 danny-bugzilla 2010-09-02 17:36:13 -0700 This bug is an open wound. Correct me if I'm wrong, but this bug is what's causing my utf-8 filenames to arrive as ? characters in the content-disposition field. Just about any solution, either the standard MIME-mandated Encoded-Word solution or Firefix/IE's html-encoding solution would be better than the dataloss that webkit currently indulges in. Who decides how to proceed? If we can get a decision, an implementation won't take long at all.