[webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

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.

>  "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.

> 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.

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.

- WBR, Alexey Proskuryakov