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

[Julian Reschke <[e-mail]>]

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.

BR, Julian