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

[Maciej Stachowiak <[e-mail]>]

On Feb 2, 2010, at 5:37 PM, Adam Barth wrote:

> On Tue, Feb 2, 2010 at 5:19 PM, Maciej Stachowiak <[e-mail]> wrote:
>> On Feb 2, 2010, at 4:30 PM, Adam Barth wrote:
>>> I'm happy to do whatever you and Ian think is best.  If the algorithm
>>> needed for HTML5 is sensible enough to be re-used by other string
>>> consumers, that would be a reason to put it in this document.  If the
>>> algorithm is non-sensical, we might be doing other applications a
>>> service keeping it HTML specific.
>> 
>> I don't actually know what algorithms current UAs use. In fact, I don't even know for sure whether non-ASCII characters in cookies are allowed at all. I guess someone needs to do some testing. I'll ask Ian if he has an opinion on which spec should define this.
> 
> I've added some basic tests using non-ASCII characters (in this case
> Chinese): charset0001, charset0002, charset0003.  IE, Firefox, Chrome,
> and Opera handle these cookies fine.  Safari does something strange
> that I haven't tracked down yet.
> 
> There's a long tail of things to test here, including invalid unicode
> in various encodings, but basic non-ASCII handling appears to do
> something somewhat sensible.  I haven't tested the document.cookie API
> at all yet.

Invalid unicode probably will not be an issue if browsers either treat these as raw bytes or treat it as a non-unicode encoding like Latin1.

Regards,
Maciej