[whatwg] HTML Cookie API
w3c at adambarth.com
Wed Feb 24 08:40:34 PST 2010
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.
More information about the whatwg