- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Wed, 7 Dec 2011 01:05:24 +0000
- To: public-webapps <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>
A new scenario just came to my attention that I thought I might
pose to the list. Given the current same-origin restrictions on
new Worker(), it is problematic for Worker usage by any JS
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
the context of the current page's domain. Relative URLs to a
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.htm
var w = 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
on the new Worker constructor:
// same setup as before
var w = new Worker("http://cdn.net/lib/workers/w1.js");
// Cross-origin failure from http://test.com/home.htm
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.
Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
previous example, would allow http://test.com/home.htm to potentially
modify any data associated with cdn.net's domain (like through
Indexed DB, or XHR, etc).
One way to allow the CDN scenario to work would be to provide an explicit
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
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
URL they are loaded from.
Thoughts from the group?
-Travis
Received on Wednesday, 7 December 2011 01:06:00 UTC