W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] HTML Cookie API

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 24 Feb 2010 08:40:34 -0800
Message-ID: <5c4444771002240840r52bc10f6yd87d97765d5a74c9@mail.gmail.com>
On Tue, Feb 23, 2010 at 10:48 PM, James Robinson <jamesr at google.com> wrote:
> On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth <w3c at adambarth.com> wrote:
>> On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth <w3c at adambarth.com> wrote:
>> >> The document.cookie API is kind of terrible. ?Web developers shouldn't
>> >> have to parse a cookie-string or prepare a properly formated
>> >> set-cookie-string. ?Here's a proposal for an HTML cookie API that
>> >> isn't as terrible:
>> >>
>> >>
>> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>> >>
>> >> I'd like to propose we include this API in a future version of HTML.
>> >> As always, feedback welcome.
> The "array-like object containing the Cookies for the document" should be a
> read-only copy of a set of objects that represent all the applicable cookies
> at some point between the request and the response. ?This needs to be really
> clear and it needs to be clear what happens if a user, say, calls
> setCookie() in the middle of iterating through the array-like object (imho
> the iteration should be unaffected).


> It's probably best to specify the ordering of Cookies in this array-like
> object to match?rfc2965's ordering rules so that users of the API don't have
> to implement this ordering themselves.

I've specced that they should be ordered as the would appear in
document.cookie.  I doubt that matches RFC 2965 because RFC 2965
differs significantly from reality.  (Although hopefully it will match
the new cookie spec.)

> Accessing cookies from script is inherently racy - there is no way to
> promise that the browser will or will not return a cookie being set by some
> HTTP response arriving "at the same time" as the getCookies() call. ?There's
> nothing really you can do about this but I think that this fact should be
> highlighted in the spec.

I've added the text "this API provides a snapshot of the data in the
cookie store at some time".

> If a U-A's privacy settings disallow script from accessing cookies, there
> should be some clear behavior. ?It looks like a U-A could make setCookie() a
> no-op and always invoke the getCookies() callback with an empty list now -
> should that be specified?

I've added an error callback to setCookie for this case.  For
getCookie, we can return an empty array.  Note that there's already a
DOM property for querying whether cookies are enabled.

Received on Wednesday, 24 February 2010 08:40:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC