[webkit-dev] Removing deprecatedFrameEncoding

Julian Reschke julian.reschke at gmx.de
Wed Jan 18 16:23:51 PST 2012


On 2012-01-19 01:00, Alexey Proskuryakov wrote:
>
> 18.01.2012, в 15:41, Julian Reschke написал(а):
>
>> We asked browser developers to write down what *they* think is needed, and didn't get a proposal -- mainly because the browsers do not interoperate on this.
>
> 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. That being said: I 
firmly believe it's a bad idea to make the semantics depend on 
out-of-band information.

> The way the Web looks from a browser is not stateless at all - a GET request can easily have side effects, you need a lot of external state to process each resource, and so on. It's hard to reach common ground when stateless nature is among the main principles of protocol design.

Please don't conflate things. Whether GET is allowed to have side 
effects is a completely orthogonal discussion.

When you say

   "you need a lot of external state to process each resource"

what exactly do you mean by that?

>> On the other hand, removing unreliable options reduces incompatibilities, untested code paths (you know what I mean), and helps developers focus on the variants that do work predictably.
>
>
> Precisely following RFC 6266 would make it so that our users would get garbage in file names when downloading from sites that work fine for them today. I do not think that there is enough potential benefit to offset that.

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?

Best regards, Julian


More information about the webkit-dev mailing list