W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Content-Disposition (new issue?)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 20 Jun 2008 15:06:30 +0000
Message-ID: <485BC74C.5010904@gmx.de>
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;

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC