- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 20 Mar 2009 22:29:52 +0000 (UTC)
On Thu, 5 Mar 2009, Drew Wilson wrote:
>
> There's currently no way to set or get cookies from workers, which
> makes various types of cookie-based operations problematic.
On Thu, 5 Mar 2009, Drew Wilson wrote:
>
> 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 running even
> after all entangled windows are closed). In that case, there may not be
> any window you can use to set cookies. I'll send more about this in a
> separate thread.
>
> Finally, there's one thing you can do with cookies that I don't think
> you can do with local storage: share data with other subdomains (i.e. if
> I'm running code under foo.example.com, I can write a cookie with
> 'domain=.example.com' and it'll be visible to code running under
> bar.example.com also). This is useful for things like single sign-on
> authentication.
It is unclear to me why you would need access to the cookies from script
to do cookie-based authentication. Isn't the server the one that sets the
cookie and the one that uses it when it is returned?
Could you elaborate on how you see the cookie API being used?
On Sat, 7 Mar 2009, Jonas Sicking wrote:
>
> 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'.
On Mon, 9 Mar 2009, Drew Wilson wrote:
>
> 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). Firefox does
> not.
I do not think there is a problem with providing self.cookie in workers,
exposing the cookie of the script. However, currently there doesn't seem
to be much support for this.
What do other browser vendors think of this?
Jonas, given the above information regarding IE's behaviour, do you still
think that providing such an API in workers is a problem?
On Fri, 6 Mar 2009, Drew Wilson wrote:
>
> There are a number of use cases where a web application would like to
> provide long-running services for the user that do not go away when the
> user closes his browser window. A canonical example of this is calendar
> notifications - a calendar application might like to have a persistent
> worker that monitors the user's calendar events, and displays
> notifications to the user when he has a meeting. Likewise, a user might
> want his mail application to display an unobtrusive notification when
> new mail arrives at the server. These are all use cases that native
> applications have supported for years, but which web-based applications
> currently have no way to achieve.
These seem like good use cases, but it's not clear what the user interface
would look like, which is probably the hardest problem here.
> Gears had an explicit permissions variable applications could check,
> which seems valuable - do we do anything similar elsewhere in HTML5 that
> we could use as a model here?
HTML5 so far has avoided anything that requires explicit permission
grants, because they are generally a bad idea from a security perspective
(users will grant any permissions the system asks them for).
> An application can create a persistent worker via the PersistentWorker()
> constructor:
>
> var worker = new PersistentWorker('worker.js', 'core');
This seems reasonable. I would recommend calling this something like
"ChromiumPersistentWorker" or some such during the experimental phase, so
as to not limit what the spec can call the feature later, though, once we
have implementation experience and can make more educated decisions as to
the design of the feature.
> The namespace for PersistentWorkers are identical to those of
> SharedWorkers - for example, if you already have a PersistentWorker
> named 'core' under a domain and a window tries to create a SharedWorker
> named 'core', a security exception will be thrown, just as if a
> different URL had been specified for two identically-named
> SharedWorkers.
Why would we not want them to use different namespaces?
> To enable these interactions, we'd add something like the following new
> APIs to the global scope for persistent workers:
>
> void open(url, optional target, optional feature, optional replace) -
> opens a browser window, just like the window.open() API which is
> available from page context
I would be very concerned about this getting abused for popups. I don't
think we want to allow arbitrary windows to be opened. I could see
allowing a kind of simple toast popup that pops up a link which, when
clicked, _then_ opens a window; would that work? Something like:
void notify(message, url);
> There isn't currently any way for workers (persistent or otherwise) to
> talk to one another without the intervention of a window, even when
> those workers exist under the same domain.
Shared workers can be opened from within workers.
> Additionally, there's no good way for workers under different domains to
> talk to one another (a window can use the cross-domain messaging
> functionality to talk to other domains, but there's no analog for this
> for workers).
This has been intentionally delayed while we wait for more implementation
experience.
On Fri, 6 Mar 2009, Dmitry Titov wrote:
>
> I have a couple of questions about Web Workers and text encoding of
> URLs. Usually, 'server' and 'path' portions of URLs are always sent in
> UTRF-8, the 'query' portion may be sent encoded if it contains non-ascii
> characters. I'm looking at what should be an encoding used for this.
The spec actually already defines this, using the term "script's character
encoding". However, this is confusing since it doesn't always correlate
with the actual encoding used for the script.
I have renamed this term to avoid the confusion.
On Fri, 6 Mar 2009, Mark S. Miller wrote:
>
> Currently, HTML5's postMessage may transfer some amount of data in the
> message, and up to one MessagePort as the port parameter. I propose that
> postMessage be modified to allow an array of MessagePorts to be
> transferred.
I have updated the spec accordingly, so that all the occurances of
MessagePort in method arguments and in events is now instead
MessagePortArray.
On Fri, 6 Mar 2009, Oliver Hunt wrote:
>
> So I've been looking at importScripts and found that the behaviour of
> Mozilla differs from the behaviour defined in the spec.
This has apparently been filed as a bug now. I have not changed the spec.
On Mon, 16 Mar 2009, Oliver Hunt wrote:
>
> So I've been looking at the object cloning rules for postMessage and have
> noticed a couple of things that seem less than ideal. The first is that it
> fails to specify the behaviour of cloning for prototype chains. While this is
> definitely an issue specific to JS rather than binding languages as a whole,
> JS is the language of the web, so if I have an object, a la:
>
> myObject = {};
> myObject.__proto__ = {foo: "bar"}
>
> Do we clone the prototype object? Do we flatten the prototype list? or
> do we drop the prototype?
This is now clarified, I hope.
> The other issue i bumped into is behaviour of ImageData/CanvasPixelArray
> -- currently (per spec) these will not be cloned, and instead have to be
> marshalled into and out of arrays by the developer. This seems less
> than ideal -- could the internal structuring algorithm be extended to
> include these types. The alternative is to allow CPA, etc to be
> automatically marshalled to arrays, which (while not ideal) would at
> least get processing correct in one direction. Unfortunately the
> developer would still have to manually marshall data coming from the
> worker, hence my preference for allowing ImageData and CPA to be cloned.
Fixed.
On Tue, 17 Mar 2009, Dmitry Titov wrote:
>
> I can't find place in the spec which would define the text encoding used
> to decode the script of the Web Worker.
Fixed.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 20 March 2009 15:29:52 UTC