[webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-19 01:42, Alexey Proskuryakov wrote:
>
> 18.01.2012, в 16:23, Julian Reschke написал(а):
>
>>> It's been communicated (see<https://lists.webkit.org/pipermail/webkit-dev/2010-November/015064.html>) that a behavior that relies on external state won't be accepted. I don't think that it's fair to blame browser vendors for not working with the group on aspects that are pre-determined to remain incompatible.
>>
>> What I said is:
>>
>> "I don't think the IETF will ever approve a standard where the encoding
>> depends on the recipient's locale, with no reliable way to find out
>> upfront what that locale is."
>>
>> So please don't claim I said something I did not say.
>
> I don't see what the difference is. Anyway, the reason why I included the link was that everyone could see your exact words.

The difference is that I stated my personal opinion and did not make a 
statement on behalf of the IETF. Nobody can do that.

Also, let me remind you that this conversation was about "documenting" 
what browsers do *instead* of requiring support for RFC 2231. We did the 
latter, and it was the right thing to do. Today, interpreting raw bytes 
is not interoperable -- browsers differ in what they do. On the other 
hand, two more major browsers have implemented RFC 5987 (which profiles 
RFC 2231 for use in HTTP), so now out of six desktop browsers I'm 
testing with, five have support for a predictable way to use non-ASCII 
characters in filenames.

>>   "you need a lot of external state to process each resource"
>>
>> what exactly do you mean by that?
>
>
> Everything is processed in a stateful manner. The behavior of a JavaScript file depends on what JavaScript files were included earlier. Decoding of most resources depends on what the referring page encoding is. Cookies are accepted or not based on browser settings. One can call this orthogonal, but there is simply not much place for stateless thinking here.

 From this list, the only thing that violates the stateless nature of 
HTTP is using out-of-band information for determining the charset. The 
other things you mentioned have nothing to do with this.

Does the HTML5 charset detection take the referrer's charset into account?

>> My understanding is that Safari, as shipping, does not use the referring page's charset for decoding the C-D filename. Or am I missing something? So what default is left? The client's locale?
>
> Yes, someone broke that. I'm in the process of adding test coverage, and fixing the regression.

If you do that it would be cool if you found out for how long it was 
broken. In any case, this part of the algorithm doesn't seem to be very 
important if nobody noticed that it's "broken" in the shipping Safari 
version.

> Besides client locale, there is UTF-8. That's actually the preferred option, which gets tried first. Only servers that send non-Unicode file names need out of band information.

How do you know for a given octet sequence whether it is UTF-8? Heuristics?

If you can write down what you think needs to be done, and can get 
Chrome/Firefox/IE/Opera on board, this may be worth documenting. I think 
that's what Adam tried ~ 15 months ago.

Best regards, Julian