[http-state] A non-string cookie API (was: non-ASCII cookie values)

Adam Barth <ietf@adambarth.com> Wed, 03 February 2010 03:59 UTC

MIME-Version: 1.0
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 02 Feb 2010 19:58:07 -0800
Message-ID: <7789133a1002021958g49bad0c4s4472ecb046f28c5e@mail.gmail.com>
To: Dan Winship <dan.winship@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: http-state@ietf.org
Subject: [http-state] A non-string cookie API (was: non-ASCII cookie values)
Precedence: list

On Tue, Feb 2, 2010 at 6:21 PM, Dan Winship <dan.winship@gmail.com> wrote:
> 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.

That's a good point.  I'll refactor the interface to the storage model
so that it can be manipulated directly by other specs without having
to serialize their requests to a set-cookie-string.

> (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.)

We can get input from long-time IETF folks, but my understanding is
that the spec should keep its normative requirements focused on
protocol messages.

Adam

[http-state] A non-string cookie API (was: non-AS… Adam Barth
Re: [http-state] A non-string cookie API (was: no… Dan Winship
Re: [http-state] A non-string cookie API (was: no… Adam Barth
Re: [http-state] A non-string cookie API (was: no… Adam Barth