RE: [Workers] Worker same-origin and usage in JS libraries...

> From: Ian Hickson [mailto:ian@hixie.ch]
> On Tue, 17 Jul 2012, Ian Hickson wrote:
> >
> > My plan is to make it so that cross-origin URLs start cross-origin
> > workers. The main unresolved question is how to do this in an opt-in
> > manner. The best idea I've come up with so far is having scripts that
> > want to opt-in to being run in such a way start with a line line:
> >
> >    // Cross-Origin Worker for: http://example.net
> >
> > ...or (for multiple domains):
> >
> >    // Cross-Origin Worker for: http://example.com https://example.org
> >
> > ...or (for any domain):
> >
> >    // Cross-Origin Worker for all origins
> >
> > ...but that doesn't seem super neat.
> 
> Just as an update, I still plan to do this, but I'm currently waiting for
> browser vendors to more widely implement the existing Worker,
> SharedWorker, MessagePort, and PortCollection features before adding more
> features to this part of the spec. It would also be helpful to have
> confirmation from browser vendors that y'all actually _want_ cross-origin
> workers, before I spec it.

I've had many folks as me why they can't just refer to a cross-origin work in the Worker constructor; after all, they can import the worker's dependent scripts via importScripts cross-origin...

The only rationale I could give is that the spec indicates the new worker's origin info was based on the document's that spawned it. If the new worker's origin info is established via the requested resource, then you should get the same functionality, but without the same-origin initial restriction. (This may be an oversimplification, but it worked for me.)

As to whether we _want_ it, these same folks are apparantely able to live with the current restrictions. They may just be deferring the bulk of the worker's content to importScripts at present to work-around this limitation.

Received on Monday, 3 December 2012 18:49:12 UTC