javascript - termine - Ejecutar trabajador web desde diferentes orígenes.

html title attribute

Question

Estoy desarrollando una biblioteca que quiero alojar en un CDN. La biblioteca se utilizará en muchos dominios diferentes en varios servidores. La biblioteca en sí contiene un script (llamémoslo script.js por ahora) que carga un trabajador web (worker.js).

Cargar la biblioteca en sí es bastante fácil: solo agregue la etiqueta <script type="text/javascript" src="http://cdn.mydomain.com/script.js"></script> al dominio en el que quiero para utilizar la biblioteca (www.myotherdomain.com). Sin embargo, dado que la biblioteca está cargando un trabajador de http://cdn.mydomain.com/worker.js new Worker(''http://cdn.mydomain.com/worker.js'') , obtengo una SecurityException. CORS está habilitado en cdn.mydomain.com.

Para los trabajadores web, no está permitido utilizar un trabajador web en un dominio remoto. El uso de CORS no ayudará: los navegadores parecen ignorarlo y ni siquiera ejecutan la verificación de verificación previa.

Una forma de evitar esto sería realizar un XMLHttpRequest para obtener la fuente del trabajador y luego crear una URL BLOB y crear un trabajador utilizando esta URL. Esto funciona para Firefox y Chrome. Sin embargo, esto no parece funcionar para Internet Explorer u Opera.

Una solución sería colocar al trabajador en www.myotherdomain.com o colocar un archivo proxy (que simplemente carga al trabajador desde el cdn usando XHR o importScripts). Sin embargo, no me gusta esta solución: requiere que coloque archivos adicionales en el servidor y, dado que la biblioteca se usa en varios servidores, la actualización sería difícil.

Mi pregunta consiste en dos partes:

1. ¿Es posible tener un trabajador en un origen remoto para IE 10+?
2. Si 1 es el caso, ¿cuál es la mejor manera de manejar el navegador cruzado?

Answer 1

Para aquellos que encuentran esta pregunta:

SÍ.

Es absolutamente posible: el truco es aprovechar un iframe en el dominio remoto y comunicarse con él a través de postMessage. El iframe remoto (alojado en cdn.mydomain.com) podrá cargar el webworker (ubicado en cdn.mydomain.com/worker.js) ya que ambos tienen el mismo origen. El iframe puede entonces actuar como un proxy entre las llamadas postmessage. Sin embargo, el script.js será responsable de filtrar los mensajes, de modo que solo se manejen los mensajes válidos de los trabajadores.

El inconveniente es que las velocidades de comunicación (y las velocidades de transferencia de datos) tienen un impacto en el rendimiento.

En breve:

• script.js agrega iframe con src="//cdn.mydomain.com/iframe.html"
• iframe.html en cdn.mydomain.com/iframe.html, ejecuta el new Worker("worker.js") y actúa como un proxy para los eventos de message de window y worker.postMessage (y al revés).
• script.js se comunica con el trabajador utilizando iframe.contentWindow.postMessage y el evento de message de la ventana. (con los controles adecuados para el origen correcto y la identificación del trabajador para varios trabajadores)