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

[whatwg] Accessing cookies from workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 5 Mar 2009 17:11:34 -0800
Message-ID: <63df84f0903051711w6dde8c79j9623d7d227f3ca11@mail.gmail.com>
On Thu, Mar 5, 2009 at 3:02 PM, Drew Wilson <atwilson at google.com> wrote:
> Hi all,
>
> There's currently no way to set or get cookies from workers, which makes
> various types of cookie-based operations problematic.
>
> I'd like to suggest that we add an API to workers to support this, via a
> "cookie" attribute on the WorkerGlobalScope interface. This cookie attribute
> would act like the document.cookie attribute from page context.
>
> When setting cookies, the cookie path would default to the path of the
> script associated with the worker. Likewise, the cookie domain would default
> to the domain of the worker itself (i.e. self.location.hostname).
>
> So, as an example:
>
> ??? var allCookies = self.cookie;
> ??? self.cookie='root_cookie=value;path=/;domain=.example.com';
>
> An alternative would be to have explicit getAllCookies() and setCookie()
> APIs, if we don't like carrying over the document.cookie paradigm.
>
> Any thoughts?

Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
something that we need to avoid to prevent users from having to deal
with locking and other thread related issues.

For what it's worth, this is a problem that exists with the
localStorage API that is also exposed in current workers draft.
Something that also needs to be fixed.

It seems like it should fine to allow reading cookies in dedicated
workers though.

/ Jonas
Received on Thursday, 5 March 2009 17:11:34 GMT

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