[whatwg] Accessing cookies from workers

[Jonas Sicking]

On Thu, Mar 5, 2009 at 6:02 PM, Drew Wilson <atwilson at google.com> wrote:
> So I get what you are saying - from an implementation standpoint, any access
> to shared data exposes the asynchronously threaded nature of workers to the
> developer, without giving them any tools to manage this access (locks, etc).
>
> For cookies, I'd always assumed that cookie state was mutable, since the
> server could set the cookie state via an HTTP response coming down in
> parallel with the execution of javascript. Perhaps the spec makes guarantees
> about the immutability of document.cookies? It doesn't seem to:
>
> "Otherwise, the user agent must act as it would when processing cookies if
> it had just attempted to fetch the document's address over HTTP, and had
> received a response with a Set-Cookie header whose value was the specified
> value, as per RFC 2109 sections 4.3.1, 4.3.2, and 4.3.3 or later
> specifications, but without overwriting the values of HTTP-only cookies.
> [RFC2109] [RFC2965]"
>
> It seems like developers shouldn't be depending on the value of
> document.cookie being static anyway.

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

Adding an API for document.cookie seems like something that we should
do since the cookies for the current script might in fact be different
from the cookies for the document that started the worker. However we
need to do this through an async API such as:

getCookie(cookieName, callbackFunction);
setCookie(cookieString, callbackFunction);

/ Jonas