[webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

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