从不同的来源执行Web worker [英] Execute web worker from different origin

问题描述

我正在开发一个我想在CDN上托管的库。该库将在多个服务器上的许多不同域上使用。

加载库本身是非常容易的：。库本身包含一个脚本（现在我们称之为script.js）加载一个web worker（worker.js）只需添加< script type =text / javascriptsrc =http://cdn.mydomain.com/script.js>< / script> 标记到我要使用库的域（www.myotherdomain.com）。但是，由于库正在从 http://cdn.mydomain.com/worker.js 加载工作者 new Worker（'http://cdn.mydomain.com/worker.js'），我得到一个SecurityException。 CORS在cdn.mydomain.com上启用。

对于Web worker，不允许在远程域上使用web worker。使用CORS不会帮助：浏览器似乎忽略它，甚至不执行预检检查。

一个办法是执行一个XMLHttpRequest来获取源的worker，然后创建一个BLOB url并使用这个url创建一个worker。这适用于Firefox和Chrome。但是，这似乎并不适用于Internet Explorer或Opera。

一个解决方案是将工作者放在www.myotherdomain.com或放置一个代理文件只需使用XHR或importScripts从cdn加载worker）。我不喜欢这个解决方案：它要求我在服务器上放置额外的文件，并且由于库在多个服务器上使用，更新将很困难。

我的问题包含两个parst：

1. 是否可能有一个远程来源的工作者用于IE 10 +？
$ b $

解决方案如果是1， div>

对于发现此问题的人：

是。

欺骗是利用远程域上的iframe并通过postMessage与它通信。远程iframe（托管在cdn.mydomain.com上）将能够加载webworker（位于cdn.mydomain.com/worker.js），因为它们都具有相同的来源。
然后，iframe可以充当postMessage调用之间的代理。然而，script.js将负责过滤消息，因此只处理有效的工作消息。

缺点是通信速度（和数据传输速度）

简而言之：

• script.js将iframe追加到 src =// cdn.mydomain.com/iframe.html


• iframe.html on cdn.mydomain.com/iframe。 html，执行 new Worker（worker.js），并作为消息


• script.js使用 iframe与工作程序进行通信。 contentWindow.postMessage 和消息事件。 （正确检查多个工人的正确来源和工人身份）

I am developing a library which I want to host on a CDN. The library is going to be used on many different domains across multiple servers. The library itself contains one script (let's call it script.js for now) which loads a web worker (worker.js).

Loading the library itself is quite easy: just add the <script type="text/javascript" src="http://cdn.mydomain.com/script.js"></script> tag to the domain on which I want to use the library (www.myotherdomain.com). However since the library is loading a worker from http://cdn.mydomain.com/worker.js new Worker('http://cdn.mydomain.com/worker.js'), I get a SecurityException. CORS is enabled on cdn.mydomain.com.

For web workers it is not allowed to use a web worker on a remote domain. Using CORS will not help: browsers seem to ignore it and don't even execute the preflight check.

A way around this would be to perform an XMLHttpRequest to get the source of the worker and then create a BLOB url and create a worker using this url. This works for Firefox and Chrome. However, this does not seem to work for Internet Explorer or Opera.

A solution would be to place the worker on www.myotherdomain.com or place a proxy file (which simply loads the worker from the cdn using XHR or importScripts). I do not however like this solution: it requires me to place additional files on the server and since the library is used on multiple servers, updating would be difficult.

My question consists of two parsts:

1. Is it possible to have a worker on a remote origin for IE 10+?
2. If 1 is the case, how is it handled best to be working cross-browser?

解决方案

For those who find this question:

YES.

It is absolutely possible: the trick is leveraging an iframe on the remote domain and communicating with it through postMessage. The remote iframe (hosted on cdn.mydomain.com) will be able to load the webworker (located at cdn.mydomain.com/worker.js) since they both have the same origin. The iframe can then act as a proxy between the postMessage calls. The script.js will however be responsible from filtering the messages so only valid worker messages are handled.

The downside is that communication speeds (and data transfer speeds) do take a performance hit.

In short:

• script.js appends iframe with src="//cdn.mydomain.com/iframe.html"
• iframe.html on cdn.mydomain.com/iframe.html, executes new Worker("worker.js") and acts as a proxy for message events from window and worker.postMessage (and the other way around).
• script.js communicates with the worker using iframe.contentWindow.postMessage and the message event from window. (with the proper checks for the correct origin and worker identification for multiple workers)

这篇关于从不同的来源执行Web worker的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！