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

[Maciej Stachowiak <[e-mail]>]

On Feb 1, 2010, at 10:54 PM, Adam Barth wrote:

> 
> On Mon, Feb 1, 2010 at 9:07 PM, David Morris <[e-mail]> wrote:
>> On Mon, 1 Feb 2010, Maciej Stachowiak wrote:
>>> But there are two ways in which it matters:
>>> 
>>> 1) A header with non-ASCII bytes get set via Set-Cookie, then read through a JS API such as document.cookie. document.cookie gives a UTF-16 encoded string, so at this point the server has to decide how to interpret non-ASCII bytes in the cookie value.
>>> 
>>> 2) If you set a cookie via document.cookie and include non-ASCII characters in the value, what bytes get sent?
>> 
>> Seems to me that the platform providing the document.cookie object is
>> responsible for making any value placed in the cookie: header correct.
> 
> That seems like a wise course of action.  This document understands
> octet sequences.  HTML5 should define how to translate those octet
> sequences into JavaScript characters (when reading document.cookie)
> and how to perform the reverse translation (when writing
> document.cookie).

HTML5 does not spec this detail and apparently expects the cookie spec to expose a string interface, not an octet-sequence interface:
http://dev.w3.org/html5/spec/Overview.html#dom-document-cookie

I think defining conversion between octet sequence and string could plausibly go in either spec. I think the cookie spec would be a better place, because other string-oriented interfaces from web platform specs to cookies (if any) should probably use the same conversion, and browser UI for managing cookies should probably use the same conversion too. So it would be a useful thing to define even if it's not used by the network protocol. However, if you don't think it should be in the cookie spec, I can file a bug against HTML5.

Regards,
Maciej