- From: Drew Wilson <atwilson@google.com>
- Date: Thu, 5 Mar 2009 17:44:05 -0800
So an asynchronous cookie setting API would look like: setCookie(cookieStr, callback) ...where the callback is invoked once the cookie has been set? I guess I don't yet entirely understand the implementation details - it sounds like there are problems accessing any shared state between workers and window context? -atw On Thu, Mar 5, 2009 at 5:35 PM, Jonas Sicking <jonas at sicking.cc> wrote: > On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman <michaeln at google.com> > wrote: > > On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman <michaeln at google.com> > wrote: > >>> 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. > >> > >> Hmmm... the cookie setting API could be async in workers. > > > > In the absence of providing such an API, one exists (provided network > > connectivity) indirectly in the form the XHR... ask the server to > > either read or set cookies values for you. > > Gecko, and I believe the latest XHR spec drafts, have disabled access > to cookies through XHR in order to prevent leaking of HTTPOnly > cookies. > > / Jonas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090305/bef643cf/attachment.htm>
Received on Thursday, 5 March 2009 17:44:05 UTC