[whatwg] Accessing cookies from workers

[Jonas Sicking]

On Sun, Mar 8, 2009 at 3:32 PM, Drew Wilson <atwilson at google.com> wrote:
>
>>
>>
>> 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?).

The closest thing to a spec for document.cookie is
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-8747038 which
probably does not require this no.

However a much more interesting question is if sites would break if
the above stopped being true. That is most definitely the case.

> 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)?

There definitely is no finalized spec here since HTML5 is the first
effort to specify alert() and it is only a draft.

I believe the above is not always going to be true in Firefox. I would
expect that this results in bugs on sites.

> It's assuredly *not*
> guaranteed to be true if you swap out that alert with a synchronous xhr.

This one is trickier since the act of doing the sync xhr can change
cookies. So it can be the same as essentially setting document.cookie
which of course would mean that a !== b.

> 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.

This is a very interesting suggestion. If we add a cookie access API
then this would seem like a reasonable thing to require from that API.

/ Jonas