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

[Adam Barth <[e-mail]>]

On Mon, Feb 1, 2010 at 10:44 AM, Julian Reschke <[e-mail]> wrote:
> Adam Barth wrote:
>>
>> On Sun, Jan 31, 2010 at 2:37 PM, eric bianchetti
>> <[e-mail]> wrote:
>>>
>>> That part does not please :
>>>
>>> The cookie-value is opaque to the user agent and MAY be anything the
>>>   origin server chooses to send, possibly in a server-selected
>>>   printable ASCII encoding.
>>>
>>> Livng and working in a non ASCII country, I tend to think we shall
>>> prepare for the coming of the other languages (Thai, Chines, Korean ....),
>>> IF a person get a cookie from a Thai server , can we securely suppose that
>>> person(computer) went to a thai site, and that person is using Thai on a
>>> daily basis? (Replace Thai by any multi bytes languages).
>>
>> The part of that sentence after the "possibly" doesn't haven any
>> normative force (it's just advice that the server can take or leave).
>> I can remove the reference to ASCII here if you like.  Julian please
>> correct me if I'm wrong, but I believe that HTTP headers typically
>> contain only ASCII characters.
>
> I think the current thinking is: "it is opaque data, but for anything
> non-ASCII you need to negotiate it out-of-band between client and server,
> and furthermore intermediaries and libraries may screw things up".
>
> So if the cookie is supposed to carry information that can't directly be
> encoded in ASCII, the best way is to use an encoding on top of it, such as
> base64.

I've reworded this sentence to clarify that the intent is as you describe:

          <t>To maximize compatibility with user agents, servers that wish to
          store non-ASCII data in a cookie-value SHOULD encode that data using
          a printable ASCII encoding, such as base64.</t>

Adam