On 2012-01-18 21:11, Alexey Proskuryakov wrote:
18.01.2012, в 11:26, Geoffrey Garen написал(а):
Once again, I think the best option is to make a decision about
deprecatedFrameEncoding based on its merits.
Most browsers respect default encoding when parsing Content-Disposition (*),
which is against the letter and spirit of RFC 6266. So I think that following
working group consensus on one spec provision is a weak argument while
disobeying other ones.
RFC 6266 is mainly concerned with defining something that will always
and reliably work. This is helpful for content providers, not browser
developers, agreed. The solution is to use RFC2231/5987 encoding. I know
you don't want to discuss this here, but anyway: Safari is the only
browser left not supporting it, and the fact it does not still forces
content authors to special-case responses based on the user agent.
(Well, similarly to legacy IEs)
RFC 6266 is not in the position to override RFC 2616. HTTPbis is, and
already is very clear in that non-ASCII characters in header fields are
unreliable, and what you posted below confirms that.
Are you aware of any *other* header fields that get this treatment? (I'm
asking because it would affect where we would put additional warnings
into the specs). Maybe WWW-Authenticate's realm parameter?
When we agree that non-ASCII bytes in Content-Disposition are be interpreted
using out of band context, I find it quite obvious that referring frame
encoding is the best piece of context we have. It's what used for subframe
default encoding as well, so ignoring it just for file names would be
inconsistent.
*) Tested a direct download of a file.
IE 9: Respects default encoding that depends on system language.
Safari 5.1.2: Respects default encoding that is configurable in preferences.
Chrome 16.0.912.75: Respects default encoding - not sure if it's manually
configurable, but it's Windows-1251 (Cyrillic) on my machine.
Firefox 9.0.1: Does not appear to respect default encoding (but then it of
course respects referring frame encoding).
Opera 11.60: Respects default encoding, but buggy for Russian primary language,
picking a different encoding than what is used for page content (ISO-8859-5
instead of Windows-1251).
...
Using the system encoding doesn't really help if you don't know the
default encoding of the recipient.
Using the referring page's encoding doesn't help if you access the link
from different referring pages, or even from somewhere else (like
clicking on a link in your mail client).
The list of test results above shows that picking an encoding based on
out-of-band information is not reliable. It may give acceptable results
in certain cases, but, for instance, wouldn't be useful for a site that
needs to work globally (think GMail).
Best regards, Julian
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
