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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
