Re: UA support for Content-Disposition header (filename parameter)

Brian Smith wrote:
> Julian Reschke wrote:
>> Brian Smith wrote:
>>> Using Content-Disposition in HTTP is an ad-hoc solution; it 
>>> isn't standardized anywhere. The IE encoding (percent-encoded 
>>> UTF-8) is not locale-sensitive; in fact, RFC 2231-based 
>>> encoding is more sensitive to locale because it allows 
>>> arbitrary (non-Unicode) encodings.
>> Furthermore, the IE encoding *is* local-sensitive; if you 
>> send percent-encoded UTF-8 to a client that isn't configured 
>> for UTF-8 encoded URIs, it doesn't work. At least it didn't 
>> when I had to deal with unhappy customers in Asia, and opened 
>> a support case.
> 
> Percent-encoded UTF-8 is not locale-sensitive. IE's parsing of it may be locale-sensitive, but the encoding itself is not.

That's true, but it really doesn't help. Percent-encoded UTF-8 doesn't 
work in a large set of IE installations.

> Actually, I just tested this out, and it seems that no matter what, IE7 breaks up the filename into [<escaped>.]<unescaped>. It decodes everything before the last period into UTF-8, but it never decodes anything after the last period into UTF-8. If there is no period then nothing is decoded. IE7 seems to work that way regardless of the UTF-8 settings used in its International settings. It is possible that it is different for Asian locales, but on my system I cannot find any correlation between the UTF-8 settings and the parsing of Content-Disposition.

I went through Microsoft's support loop in 2004, and all they could tell 
me that there is no encoding that will work with all IE installations.

>> The profile would be:
>>
>> - no line folding (continuations)
>> - use the encoding from 
>> <http://greenbytes.de/tech/webdav/rfc2231.html>
>> with the encoding being hardwired to "utf-8".
> 
> That sounds a lot more reasonable. But, I'd rather have the HTTP specification say that than the HTML specification. Since RFC 2616 already talks about Content-Disposition at length, and since Content-Disposition is widely implemented, I think it is within the HTTP WG charter to formally specify Content-Disposition's use in HTTP. Otherwise, a separate RFC detailing this profile would be better than specifying it in the HTML spec.

It may make sense to do that in RFC2616bis, but I still think it would 
be good if HTNL5 told UA implementors: "you really need to do this".

> I think it is easier to get the open-source browsers changed to decode <filename> if-and-only-if it is a valid percent-encoded UTF-8 sequence, than it is to get support for <filename*> into Internet Explorer. Firefox has a "IE parity" goal that helps fast-track such changes, maybe WebKit/KHTML does as well. Further, even if <filename*> support was added to Internet Explorer, maybe the IE team has some reason for decoding <filename> the way it does. In that case, IE might end up parsing <filename*> the same way it parses <filename>, in which case nothing would be gained. It would be nice if somebody on the IE team could describe how they handle Content-Disposition, and why they handle it that way.

The problem with that is:

- it's not backed by a spec,
- it breaks existing deployments (the recipient doesn't know whether to 
percent-escape or not),
- it won't fix the problem for many IE installations anyway.

By any chance: is somebody from Microsoft listening to this?

BR, Julian

Received on Saturday, 22 March 2008 00:08:58 UTC