Re: Content-Disposition (new issue?)

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