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

Adam Barth <> Tue, 02 February 2010 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 475D73A67F3 for <>; Mon, 1 Feb 2010 22:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.865
X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10s81GooJHuC for <>; Mon, 1 Feb 2010 22:54:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5F62C3A6A50 for <>; Mon, 1 Feb 2010 22:53:57 -0800 (PST)
Received: by pxi16 with SMTP id 16so5707884pxi.29 for <>; Mon, 01 Feb 2010 22:54:32 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id e12mr3667840wfa.332.1265093672112; Mon, 01 Feb 2010 22:54:32 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Adam Barth <>
Date: Mon, 01 Feb 2010 22:54:12 -0800
Message-ID: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Feb 2010 06:54:02 -0000

On Mon, 1 Feb 2010, Maciej Stachowiak wrote:
> We do have to define what happens if there are non-ASCII characters in a header value. Presumably, if such bytes are set via Set-Cookie, then the Cookie header just echoes them back, so we can treat them as opaque. (That's assuming there is no requirement to reject non-ASCII cookie values.)

That's correct.  I've filed a ticket for adding a test case for
non-ASCII cookie values.

On Mon, Feb 1, 2010 at 9:07 PM, David Morris <> 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