[whatwg] Accessing cookies from workers

Drew Wilson atwilson at google.com
Mon Mar 9 11:38:21 PDT 2009

On Mon, Mar 9, 2009 at 10:23 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> The problem is that people are likely to write code like:
> if (self.getAllCookies() != "magic value") {
>  a = self.getAllCookies();
>  ...do stuff...
> }
> at that point it's entirely possible for 'a' to have the value "magic
> value" which is likely to cause the script to break.

Here we are making assumptions about how people will use routines that don't
actually exist yet. If you were to substitute "new Date().getTime()" for
"self.getAllCookies()" in the code above, I think we'd all agree that the
user expectation is faulty - is it not feasible to state that, just like
Date().getTime(),. getAllCookies() returns a snapshot of a mutable value?

I'm OK with making setCookie() asynchronous, because I think there may be a
valid point that you don't want new worker code to suddenly break existing
JS code that expects document.cookies to remain immutable across a single
block of execution. But I don't see that argument extending to

> Indeed. It does seem like you would be able to ask ;)

I'm looking into this now, actually :) - I'll let you know what I find out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090309/500f46e5/attachment-0002.htm>

More information about the whatwg mailing list