WebKit based browsers do not support headers with non-ASCII parameters according to RFC 2231 <http://www.ietf.org/rfc/rfc2231.txt>. This format is supported by Firefox. Related: - http://moinmo.in/MoinMoinBugs/Non_ASCII_attachments_names_corrupted_on_download
Created attachment 16398 [details] CGI script demonstrating the problem To reproduce: 1. Install script 2. Access 3. File > Save As Result: file name is download.py Expected: file name should be עברית Another way: 1. Add link to this script in another html document, e.g. <a href="cgi-bin/download.py">download</a> 2. Right click the link and choose "Download linked file" Result: download to file "download.py" Expected: download to file "עברית" Firefox give expected result in both cases.
<rdar://problem/5475999>
The changes required to support this completely need to be implemented at a lower level than WebKit. This work is being tracked by the associated Radar. I'm going to close this bug as INVALID as the issue is not at the WebKit level. Thanks for the bug report.
See also: rdar://4727992
It would be great if somebody could update this bug with information about how work on rdar://4727992 is progressing.
As it is not a WebKit bug it is not appropriate for us to publish information about it in the WebKit bug database.
*** Bug 20407 has been marked as a duplicate of this bug. ***
regarding comment 1 and it's attachment... The test case is incorrect. It uses filename*="utf-8'en'%D7%A2%D7%91%D7%A8%D7%99%D7%AA" while it should be filename*=utf-8'en'%D7%A2%D7%91%D7%A8%D7%99%D7%AA according to the "extended-initial-value" production in Section 7 of RFC 2231 (<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.7>)
Created attachment 22834 [details] Fixed test case This test case does not work with Safari 3.1.2 and Mac OS X 10.4.11, but works with Firefox 2 on same system.
(In reply to comment #8) > filename*="utf-8'en'%D7%A2%D7%91%D7%A8%D7%99%D7%AA" > filename*=utf-8'en'%D7%A2%D7%91%D7%A8%D7%99%D7%AA AFAICT, these only differ in that the original one has quotation marks. Could you please clarify why they are no allowed? It is strange to me because (1) extended-initial-value is not referenced anywhere else in RFC 2231, so formally speaking, it does not mean anything; and (2) RFC 2231 itself has an example that uses quoted strings: Content-Type: application/x-stuff title*0*=us-ascii'en'This%20is%20even%20more%20 title*1*=%2A%2A%2Afun%2A%2A%2A%20 title*2="isn't it!" Does the variant with quotations marks work in other browsers?
> AFAICT, these only differ in that the original one has quotation marks. Yes. > Could you please clarify why they are no allowed? It is strange to me because > (1) extended-initial-value is not referenced anywhere else in RFC 2231, so That's a known erratum, see http://www.rfc-editor.org/errata_search.php?eid=477. > formally speaking, it does not mean anything; and (2) RFC 2231 itself has an > example that uses quoted strings: But not in the initial value. > Does the variant with quotations marks work in other browsers? I'm going to test it, but I'm really not sure why it would matter. The spec is there for a reason.
More test cases: <http://greenbytes.de/tech/rfc2231/> Proposed profile for use of RFC2231 encoding in HTTP: <http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html>
(In reply to comment #12) > More test cases: <http://greenbytes.de/tech/rfc2231/> http://greenbytes.de/tech/tc2231/
In the meantime, draft-reschke-rfc2231-in-http has been published as IETF RFC 5987 on the standards track.