Re: [http-state] [httpstate] #11: Consider defining how to map a cookie-string into unicode

[Adam Barth <[e-mail]>]

On Thu, Mar 11, 2010 at 11:06 PM, Anne van Kesteren <[e-mail]> wrote:
> On Thu, 11 Mar 2010 00:19:07 +0100, httpstate issue tracker
> <[e-mail]> wrote:
>>
>> #11: Consider defining how to map a cookie-string into unicode
>>
>> --------------------------------+-------------------------------------------
>>  Reporter:  ietf@…              |        Owner:
>>     Type:  defect              |       Status:  closed
>>  Priority:  major               |    Milestone:
>> Component:  cookie              |      Version:
>>  Severity:  -                   |   Resolution:  fixed
>>  Keywords:                      |
>>
>> --------------------------------+-------------------------------------------
>> Changes (by ietf@…):
>>
>>  * status:  new => closed
>>  * resolution:  => fixed
>>
>>
>> Comment:
>>
>>  As discussed on the list:
>>
>>  The draft treats the cookie values as opaque octets throughout for use
>>  on the wire.  I've added a SHOULD-level requirement to use a UTF8 when
>>  converting the octets to characters (e.g., for use in the user agent's
>>  user interface).
>>
>>  Given that the encoding issue doesn't appear to affect
>>  interoperability on the wire, I think a SHOULD-level recommendation is
>>  appropriate here.  If specific APIs (e.g., document.cookie) have more
>>  specific needs, they can add additional requirements.
>
> FWIW, XMLHttpRequest inflates/deflates bytes for HTTP header values. I.e.
> uses ISO-8859-1 (not mapped to Windows-1252 in this specific instance). I
> would assume document.cookie behaves the same in most browsers...

As discussed earlier, some browsers apparently use UTF-8 for
document.cookie and others use ISO-8859-1:

http://github.com/abarth/http-state/blob/master/notes/2010-02-03-Julian-Reschke.txt

Adam