Re: [http-state] non-ASCII cookie values (was Re: Closing

eric bianchetti <> Wed, 10 February 2010 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02C783A7281 for <>; Tue, 9 Feb 2010 18:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aUF8X4dCHnBk for <>; Tue, 9 Feb 2010 18:30:31 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id C9EAD3A67A4 for <>; Tue, 9 Feb 2010 18:30:30 -0800 (PST)
Received: (qmail 99476 invoked by uid 60001); 10 Feb 2010 02:31:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1265769096; bh=GDytTC9ZKwuJ9V00tdTBz0/Y02bwziZAduEp8OGZAB4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ejj0vaNAJlXvGg1W/bpyRgAAU6aJFShSbLjGTUZceOUqy6lhi2CULEqdoRB92DOPeungIcIug34MqO2n08SFU6DJbvMX4hTMI/6tl2lkpefZvntQ0IhRKWjMqipxNGvo8fHlrgRtz8fy86xq+zQmsGWnMJ7JQXjo5ATOd0QObak=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0jMeApYf0kz4l+ldsd+OY+YykV+pQqGBgEssjBskOjLE51WeuweNLetY4SicLOD8NZtLixIdLTKzzvf2ACK1HJI0z07cPwFuQJMzs5Q+OmNL5nfmzwVrBCJ3iGMYw7joNO9WyrCBo2f2npp+611SBgB1wQcXR9IUL8Vvwf+/2Os=;
Message-ID: <>
X-YMail-OSG: quIIc8EVM1l4MUShZIzu4sYF5.BTWBA5n.mTQuPeJuhb34PP7_avrYlKhl1yDkgO0X9VFxOBD4uKSrqIJkzV5.7.V5USRjrST1a75q8RhU_RRRszcTqAFHReOAO1RbIZ_eogpS5gMRvJh5XWfFXlsGHuZf_SqsdDV2aGgiTgoeKtuZQQJ7alMpnnTEEU5qvMfA3fATwUvGr3QuukgsJZPKtzYaWn1j2mEDij5wqICYbyfR4hCpE2u03vfynIS02xPNMOWzozzFeD4GWrJx2R1X48e93hEMbTlLe.gsYsVZdsK3lol426VF.Es0xJhtFoeTpIZbBdC.r2QSby5H9vcFLmmTKk8IsIoHyI
Received: from [] by via HTTP; Tue, 09 Feb 2010 18:31:36 PST
X-Mailer: YahooMailRC/272.7 YahooMailWebService/
References: <>
Date: Tue, 9 Feb 2010 18:31:36 -0800 (PST)
From: eric bianchetti <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Feb 2010 02:30:32 -0000

It was the idea that made me point on the non-ASCII characters. At one moment in a near future we will have to go for them.

Working in a non-ASCII country since 2002 (Thailand); I can tell there is need to include (non normatively for now) non-ASCII characters in the specs (for human and technical reasons).

Some generals wordings , such precising non ASCII have to be encoded (would it be better to precise or not-precise the encoding?) if they are used for cookies. 


Message: 2
Date: Tue, 9 Feb 2010 08:47:58 -0800
From: Adam Barth <>
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing
    Ticket 3:    Public Suffixes)
To: Julian Reschke <>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 3, 2010 at 12:50 AM, Julian Reschke <> 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

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