22 messages in org.w3.public-htmlRe: UA support for Content-Dispositio...| From | Sent On | Attachments |
|---|---|---|
| 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: | Julian Reschke (juli...@gmx.de) | |
| Date: | Mar 21, 2008 5:07:53 pm | |
| List: | org.w3.public-html | |
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