- 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