- 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