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

Adam Barth <ietf@adambarth.com> Tue, 02 February 2010 06:49 UTC

Return-Path: <adam@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2213A6800 for <http-state@core3.amsl.com>; Mon, 1 Feb 2010 22:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySbJrrUflKWa for <http-state@core3.amsl.com>; Mon, 1 Feb 2010 22:49:29 -0800 (PST)
Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 34DE33A67CC for <http-state@ietf.org>; Mon, 1 Feb 2010 22:49:29 -0800 (PST)
Received: by pzk36 with SMTP id 36so6566277pzk.5 for <http-state@ietf.org>; Mon, 01 Feb 2010 22:50:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.5.37 with SMTP id 37mr251311wfe.329.1265093402192; Mon, 01 Feb 2010 22:50:02 -0800 (PST)
In-Reply-To: <4B67210F.3020709@gmx.de>
References: <7789133a1002011014x5d587436j663a73bc92270a65@mail.gmail.com> <4B67210F.3020709@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 1 Feb 2010 22:49:42 -0800
Message-ID: <7789133a1002012249y68cdc54ave68a5b7fe52e80f6@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: eric bianchetti <eric_bianchetti@yahoo.com>, http-state@ietf.org
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2010 06:49:30 -0000

On Mon, Feb 1, 2010 at 10:44 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Adam Barth wrote:
>>
>> On Sun, Jan 31, 2010 at 2:37 PM, eric bianchetti
>> <eric_bianchetti@yahoo.com> 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