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

Dan Winship <> Wed, 03 February 2010 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C2563A6BB7 for <>; Tue, 2 Feb 2010 18:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9VZi68M8puO6 for <>; Tue, 2 Feb 2010 18:21:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B4C7A3A6BAB for <>; Tue, 2 Feb 2010 18:21:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPA id 9B1FC802AE; Tue, 2 Feb 2010 21:21:54 -0500 (EST)
Message-ID: <>
Date: Tue, 02 Feb 2010 21:21:53 -0500
From: Dan Winship <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Maciej Stachowiak <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Wed, 03 Feb 2010 02:21:15 -0000

On 02/02/2010 07:27 PM, Maciej Stachowiak wrote:
> HTML5 does not spec this detail and apparently expects the cookie
> spec to expose a string interface, not an octet-sequence
> interface:

Slight tangent...

One of the major reasons cookies are such a disaster is that web site
frameworks and document.cookie both expose cookies to web site authors
as just strings, and expect the web site authors to get all the nasty
syntax details correct. Which they of course don't.

Although in the short term we need to nail down exactly how
document.cookie works for backward-compatibility purposes, in the long
run, we might be able to make the world a better place if we helped
design a fabulous new higher-level cookie API for HTML5, where the
browser would handle the tricky syntax bits, and would just throw an
exception if the page tried to use an illegal cookie name, etc. This new
API could even fix some issues that we aren't currently able to fix in
the spec, eg, by setting the "Secure" flag on the cookie by default if
the page had been loaded over https, etc.

(And likewise, the spec could recommend that web site
frameworks/libraries SHOULD provide similar idiot-proof high-level
cookie APIs, rather than expecting authors to generate valid Set-Cookie
headers by themselves.)

-- Dan