|Julian Reschke||Mar 14, 2008 6:48 am|
|Lachlan Hunt||Mar 14, 2008 7:42 am|
|Julian Reschke||Mar 14, 2008 7:50 am|
|Julian Reschke||Mar 14, 2008 7:54 am|
|Lachlan Hunt||Mar 14, 2008 8:01 am|
|Julian Reschke||Mar 14, 2008 8:17 am|
|Michael A. Puls II||Mar 14, 2008 9:25 am|
|Julian Reschke||Mar 14, 2008 9:38 am|
|Brian Smith||Mar 14, 2008 11:45 am|
|Julian Reschke||Mar 14, 2008 12:04 pm|
|Maciej Stachowiak||Mar 15, 2008 10:54 pm|
|Julian Reschke||Mar 16, 2008 4:02 am|
|Maciej Stachowiak||Mar 16, 2008 11:34 am|
|Julian Reschke||Mar 16, 2008 12:00 pm|
|Maciej Stachowiak||Mar 16, 2008 3:46 pm|
|Karl Dubost||Mar 16, 2008 10:56 pm|
|Leif Halvard Silli||Mar 17, 2008 11:45 am|
|Julian Reschke||Mar 17, 2008 2:35 pm|
|Brian Smith||Mar 18, 2008 9:01 am|
|Julian Reschke||Mar 18, 2008 9:58 am|
|Brian Smith||Mar 21, 2008 9:24 am|
|Julian Reschke||Mar 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|
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
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