[whatwg] HTML Cookie API
jamesr at google.com
Tue Feb 23 22:48:33 PST 2010
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:
> >> I'd like to propose we include this API in a future version of HTML.
> >> As always, feedback welcome.
> > I really think the API should be asynchronous, as to avoid the mess
> > that .localStorage currently is.
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.
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.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg