- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 20 Jun 2008 15:06:30 +0000
- To: Brian Smith <brian@briansmith.org>
- Cc: ietf-http-wg-request@w3.org
Brian Smith wrote: > Julian Reschke wrote: >> Brian Smith wrote: >>> ... Documenting the *real* current situation would be much >> more useful, even though the current situation sucks; at >> least if people know the problem they can try to work around >> it. Especially, it would be great if there were some public >> test cases that describe the problem. >>> ... >> The problem is that there simply is no workaround for IE that >> works independently of the locale IE is running in. (Yes, we >> did report the issue to Microsoft back in 2004, and they were >> unable to provide a solution that would work the same way >> with IE across all locales) > > Could you please share a test case? Every time I tried to reproduce the > problem I could not. For IE, the only way (I'm aware of) to provide non-ASCII characters in the Content-Disposition filename parameter is to use percent encoding, such as Content-Disposition: attachment; filename=%c3%a4%c3%b6%c3%bc%c3%9f%e2%82%ac.txt for a filename of "äöü߀". The issue with that is that what character encoding IE chooses to *decode* the byte sequence depends on locale and IE configuration. For instance, in western countries it uses UTF-8, while in Asian locales, it uses something else, *except* when the config option "send URLs in UTF-8" is selected (which IMHO is *not* the default over there). And even *if* this would work across all IE installations, it would break all the other UAs, which take the parameter value verbatim. Adding support for RFC2231 (or a profile of it) should be trivial for Microsoft, as currently, a parameter such as Content-Disposition: attachment; *filename=charset'lang'value is simply ignored. BR, Julian
Received on Friday, 20 June 2008 20:07:06 UTC