WebKit does not support non ascii parameters defined in RFC2231

• Component: New Bugs
• Status: CLOSED INVALID

[Nir Soffer]

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

[Nir Soffer]

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.

[Mark Rowe (bdash)]

<rdar://problem/5475999>

[Mark Rowe (bdash)]

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.

[Alexey Proskuryakov]

See also: rdar://4727992

[Julian Reschke]

It would be great if somebody could update this bug with information about how work on rdar://4727992 is progressing.

[Mark Rowe (bdash)]

As it is not a WebKit bug it is not appropriate for us to publish information about it in the WebKit bug database.

[Mark Rowe (bdash)]

*** Bug 20407 has been marked as a duplicate of this bug. ***

[Julian Reschke]

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>)

[Nir Soffer]

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.

[Alexey Proskuryakov]

(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?

[Julian Reschke]

> 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.

[Julian Reschke]

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>

[Nir Soffer]

(In reply to comment #12)
> More test cases: <http://greenbytes.de/tech/rfc2231/>
http://greenbytes.de/tech/tc2231/

[Julian Reschke]

In the meantime, draft-reschke-rfc2231-in-http has been published as IETF RFC 5987 on the standards track.