W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Accessing cookies from workers

From: Drew Wilson <atwilson@google.com>
Date: Sun, 8 Mar 2009 15:32:21 -0700
Message-ID: <f965ae410903081532h29eabcb7r58a43fa95fffa22c@mail.gmail.com>
>
>
> document.cookies can't change in the middle of an execution. I.e. a script
> like:
>
> a = document.cookie;
> b = document.cookie;
> alert(a === b);
>
> will always show 'true'.


Is that strictly true? Can you point me to the appropriate part of the spec,
because I couldn't find anything relevant other than what I previously
quoted, and that doesn't seem to make any guarantees for the stability of
document.cookies (perhaps the spec itself needs to be clarified to provide
those guarantees?). Guaranteeing that relationship seems to imply that we
ignore cookies set by network calls that happen in parallel with the current
thread of javascript execution.

What if I do something like this:

a=document.cookie
alert("now is the time to block our execution to allow HTTP requests to
finish")
b=document.cookie

Is a===b still guaranteed to be true (maybe so)? It's assuredly *not*
guaranteed to be true if you swap out that alert with a synchronous xhr.

Anyhow, I'm not averse to having an asynchronous API, but I'd still like to
enable workers to do this:

setCookie("cookiestring")
xhr.send();

Forcing workers to do all of their cookie-laden network requests via a
double-callback (set cookie, wait for callback, invoke xhr, wait for
response) seems too cumbersome.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090308/f359ffa2/attachment.htm>
Received on Sunday, 8 March 2009 15:32:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT