On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking jo...@sicking.cc wrote:
However a much more interesting question is if sites would break if
the above stopped being true. That is most definitely the case.
Agreed - existing behavior trumps spec ambiguity. However, in this case I
was assuming
On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson atwil...@google.com wrote:
On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking jo...@sicking.cc wrote:
However a much more interesting question is if sites would break if
the above stopped being true. That is most definitely the case.
Agreed - existing
On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
This can be even worse: how would you syncronize the code in the
callback with code right after the call? You don't
On Mon, Mar 9, 2009 at 10:23 AM, Jonas Sicking jo...@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
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
This can be even worse: how would you syncronize the code in the
callback
Following up on this. I created two pages, one that tests cookies in a loop,
and one that sets cookies in a loop, and ran them in separate windows in
Firefox 3, IE7, and Chrome.
Chrome and IE7 currently allow concurrent modification of document.cookies
(i.e. the test loop throws up an alert).
On Mon, Mar 9, 2009 at 11:46 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:01 AM, Giovanni
and most important
3) why it did actually happen in my code? (using an async XHR)
Not sure what you are saying here. Do you have example code.
I think what he's talking about the issue described at
http://www.nerdgod.com/ie7test2.html.
I was CC'd on an email thread about this last year
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
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)
On Thu, Mar 5, 2009 at 6:02 PM, Drew Wilson atwil...@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,
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
On Thu, Mar 5, 2009 at 3:02 PM, Drew Wilson atwil...@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
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
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@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
On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman micha...@google.com wrote:
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@google.com wrote:
Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking jo...@sicking.cc wrote:
Gecko, and I believe the latest XHR spec drafts, have disabled access
to cookies through XHR in order to prevent leaking of HTTPOnly
cookies.
Yes, cookies are no longer exposed through XMLHttpRequest in any way per
the
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@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
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
On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson atwil...@google.com wrote:
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
In my particular case, I'm trying to figure out how to use cookie-based
authentication from workers.
I could use postMessage() to a main window to set cookies. However, I have
another motivation for exploring this: my team is planning to experiment
with persistent workers (workers that continue
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,
Drew Wilson wrote:
(workers that continue running even after all entangled windows are closed).
On a side note, why would a UA allow these? Once a user leaves a site,
the site shouldn't be using any more CPU on the user's computer, no?
-Boris
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking jo...@sicking.cc wrote:
Gecko, and I believe the latest XHR spec drafts, have disabled access
to cookies through XHR in order to prevent leaking of HTTPOnly
cookies.
On Fri, 06 Mar 2009 12:56:43 +0900, Michael Nordman micha...@google.com
wrote:
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren ann...@opera.com
wrote:
Yes, cookies are no longer exposed through XMLHttpRequest in any way
per the specification.
So am i to understand that cookies headers
postMessage()? :-)
I'm still wondering if we're just trying to ensure behavior (allowing JS
code to access the cookies without having them change asynchronously) that
the spec fundamentally doesn't guarantee anyway.
-atw
Jonas (and I) were talking about setRequestHeader(),
getAllResponseHeaders(), and getResponseHeader().
Sure.
postMessage()? :-)
That certainly works for dedicated workers. Not so great for shared
workers or persistent workers. In the shared case, the postMessage
sender and receiver would
27 matches
Mail list logo
