Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)

[Adam Barth <[e-mail]>]

On Wed, Feb 3, 2010 at 12:50 AM, Julian Reschke <[e-mail]> wrote:
> Adam Barth wrote:
>> In general, I'm very reluctant to specify a behavior that conflicts
>> with IE, Firefox, Chrome, and Opera.  In specific, IE has something
>> like 99% market share in some Asian markets.  The fact that this issue
>> affects Asian markets disproportionately means the pressure to be
>> IE-like is even greater than usual.
>> ...
>
> On the other hand, why require something that's known not be in use (if that
> is the case)?

As Maciej points out, this is not the standard of evidence that user
agent implementors usually use when making compatibility decisions.  I
understand that this is a bit of a cultural divide in this group, but
I'll try to give you a flavor of why UA folks think this way.

A number of months ago, I helped change the way JavaScript prototypes
were configured in WebKit.  Instead of using the lexical or dynamic
scope (which is what WebKit was using a mix of at the time), we
changed them to some other esoteric rule that matched Firefox and IE.
At the time, we had zero evidence that this change had any
compatibility because the cases where these things are different are
extremely obscure.  So, why did we change it?  Well, because there's
no value in being different from other browsers and some (potential)
value in being the same.  That means the benefit (potentially
non-zero) outweighs the cost (essentially zero).

Now, as far as I know, the project still has zero evidence that this
change actually improved compatibility in the real world.  However, I
happen to know by some random coincidence that this change was hugely
beneficial.  It just so happens that when folks use both Selenium (a
popular web application testing harness) and Prototype.js (a popular
JavaScript library), they arrive in precisely the situation where
these computations give different answers.  Without the change,
developers have a lot of trouble testing a Prototype.js-using web site
with Selenium, but, with the change, it works fine.

So what are the consequences of the change?  Well, it means developers
are much more likely to test their web sites in Safari because they
can just re-use their existing Selenium tests instead of having to
build or find another testing harness.  That means they're more likely
to fix bugs that affect Safari, which means their web sites will work
better in Safari.  That, in turns, means users of Safari will have
better experiences at web sites and the marketshare of Safari will
grow.

If the WebKit project had required actual examples of the change being
beneficial, they probably would not have made that change and would
not have enjoyed the benefits.  Now, not every change pays off as well
as the one I describe, and, in many cases, we never find out how well
they pay off.  The point is more that user agent implementing are
being rational when they make these sorts of decisions.

> If you allow non-ASCII characters (or actually require support), you'll also
> have to figure out how existing server and client based APIs are to deal
> with them (so what encoding is it?).

For our purposes, it doesn't really matter how existing servers handle
the encodings.  In the end, they do what they do.  As long as we send
the "right" bytes on the wire, they'll do the "right" thing, whatever
that is.  As for client APIs, yes, we'll need to get that right,
either in this specification or in the specification of those APIs (as
we've discussed elsewhere in this thread).

Adam