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

From: Adam Barth <[email-masked]>
Date: Tue, 2 Feb 2010 19:58:07 -0800

On Tue, Feb 2, 2010 at 6:21 PM, Dan Winship <[email-masked]> 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

---

From: Dan Winship <[email-masked]>
Date: Wed, 03 Feb 2010 09:24:23 -0500

> that the spec should keep its normative requirements focused on

OK, maybe s/SHOULD/should/ then, but see below too.

On 02/03/2010 02:42 AM, Daniel Stenberg wrote:
> Don't we pretty much assume and wish for this for every spec and
> protocol? I mean, we make a smaller set of libraries and frameworks for
> everything that then a large amount of users can use.
> 
> It is really the job of this spec to spell it out?

It's advice based on past implementation experience. We know that lots
of web site authors are going to generate invalid Set-Cookie headers if
their APIs let them. So we should encourage framework authors to provide
better APIs, because that means there will be more valid protocol
messages going over the wire and fewer invalid ones.

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Wed, 3 Feb 2010 08:47:36 -0800

I think what you're suggesting is to make this advice non-normative,
which seems like a good idea.

Adam

---

From: Adam Barth <[email-masked]>
Date: Tue, 9 Feb 2010 10:20:26 -0800

Done.