asking for UA developer's feedback on Content-Disposition filename I18N issue

Hi,

our chair suggested to me that I summarize & repost this issue, in order 
to collect feedback from the developers of UAs who may have missed 
previous discussions on this mailing list (and the httpbis mailing 
list). So...:

- RFC2183 defines the Content-Disposition header 
(<http://tools.ietf.org/html/rfc2183>)

- RFC2616 (HTTP/1.1) defines the Content-Disposition header, as used in 
HTTP (<http://tools.ietf.org/html/rfc2616#section-19.5.1>)

- As far as I can tell, all major UAs implement simple cases, such as

   Content-Disposition: attachment; filename="fname.ext"

- HTTP/1.1 does not allow non-ISO8859-1 characters in headers, so the 
simple format can not be used for filenames that use non ISO8859-1 
characters.

- For this case, RFC2231 defines escaping rules 
(<http://tools.ietf.org/html/rfc2231>). A simple example would be:

    Content-Disposition: attachment;
      filename*=utf-8'en-us'%c3%a4%c3%b6%c3%bc%c3%9f%e2%82%ac.txt

   for a filename of "äöü߀.txt".

- This has been implemented for a long time now in Firefox and Opera.

- Other UAs do not seem to provide any reliable way to transport 
non-8859-1 characters in the filename.

- Implementing the RFC2231-style escaping would be backwards-compatible; 
right now, for instance, IE simply ignores the extended format.

- More discussion: around 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=5773#c7> (HTML WG's 
Bugzilla) and (HTTPbis mailing list) 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0600.html>.

 From those UA implementors who do not implement this, I'd like to find 
out what the chances are that this may be supported in future releases. 
What's holding you back? Are there any issues with the combo of 
RFC2616/RFC2183/RFC2231 that need to be addressed?

BR, Julian

Received on Thursday, 26 June 2008 12:29:52 UTC