<9768D477C67135458BF978A45BCF9B38381C3D09@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
Current votes: None.
A new scenario just came to my attention that I thought I might=20
pose to the list. Given the current same-origin restrictions on=20
new Worker(), it is problematic for Worker usage by any JS=20
libraries on a CDN.
A site using a CDN simply provides an absolute URL reference to
the library, and it is subsequently downloaded and executed in=20
the context of the current page's domain. Relative URLs to a=20
worker script will resolve according to the domain of the hosting
page:
// http://cdn.net/dowork.js which was included from http://test.com/home.ht=
m=20
var w =3D new Worker("lib/workers/w1.js");
// Tries to open http://test.com/lib/workers/w1.js
and absolute URLs will fail due to the cross-origin restrictions=20
on the new Worker constructor:
// same setup as before
var w =3D new Worker("http://cdn.net/lib/workers/w1.js");
// Cross-origin failure from http://test.com/home.htm=20
I looked back through the list and at the original worker proposals
to try and discover why the same-origin restrictions is in place.
The root of the issue seems to be the expectation that WorkerGlobalScope
runs and executes everything according to its own location.URL.=20
Thus, allowing http://cdn.net/lib/workers/w1.js to load in the=20
previous example, would allow http://test.com/home.htm to potentially=20
modify any data associated with cdn.net's domain (like through=20
Indexed DB, or XHR, etc).
One way to allow the CDN scenario to work would be to provide an explicit=20
way to tell a worker to run in the host context, rather than the context
that the Worker is loaded from (which is what <script> inclusion and
importScripts does today).
Since Workers _can't_ be loaded cross-origin [currently], the Workers
are already running in the host context by virtue of this limitation.
Codifying that a WorkerGlobalScope's execution environment is always=20
that of the document that created it, and then allowing workers to be
constructed from any URL would effectively solve the CDN problem IMHO.
Later, when/if we open up cross-origin workers, we can provide a special
way to instruct the workers to set their execution context to that of the=20
URL they are loaded from.
Thoughts from the group?
-Travis