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

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.

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.

> > This is valid according to RFC 2231 but Firefox and 
> > Thunderbird do *NOT* parse it correctly; they assume the 
> > parts of the filename are listed in order. So, there are no 
> > fully conforming HTTP+Content-Disposition+RFC2231 implementations.
> 
> That is probably true, thus it would make sense to specify 
> the profile that UAs are expected to implement, and this is 
> exactly the reason why I came here with this issue.
> 
> 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.

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.

- Brian

Received on Friday, 21 March 2008 16:25:05 UTC