atom feed22 messages in org.w3.public-htmlRE: UA support for Content-Dispositio...
FromSent OnAttachments
Julian ReschkeMar 14, 2008 6:48 am 
Lachlan HuntMar 14, 2008 7:42 am 
Julian ReschkeMar 14, 2008 7:50 am 
Julian ReschkeMar 14, 2008 7:54 am 
Lachlan HuntMar 14, 2008 8:01 am 
Julian ReschkeMar 14, 2008 8:17 am 
Michael A. Puls IIMar 14, 2008 9:25 am 
Julian ReschkeMar 14, 2008 9:38 am 
Brian SmithMar 14, 2008 11:45 am 
Julian ReschkeMar 14, 2008 12:04 pm 
Maciej StachowiakMar 15, 2008 10:54 pm 
Julian ReschkeMar 16, 2008 4:02 am 
Maciej StachowiakMar 16, 2008 11:34 am 
Julian ReschkeMar 16, 2008 12:00 pm 
Maciej StachowiakMar 16, 2008 3:46 pm 
Karl DubostMar 16, 2008 10:56 pm 
Leif Halvard SilliMar 17, 2008 11:45 am 
Julian ReschkeMar 17, 2008 2:35 pm 
Brian SmithMar 18, 2008 9:01 am 
Julian ReschkeMar 18, 2008 9:58 am 
Brian SmithMar 21, 2008 9:24 am 
Julian ReschkeMar 21, 2008 5:07 pm 
Subject:RE: UA support for Content-Disposition header (filename parameter)
From:Brian Smith (bri@briansmith.org)
Date:Mar 21, 2008 9:24:03 am
List:org.w3.public-html

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