I ran into an interesting problem while creating a hosted API that relies on web workers. I was hoping to get a little community feedback on it.
My server is set up with the appropriate CORS headers to deliver the worker JS files and can be retrieved with an XMLHttpRequest object. However, when the URL is given to new Worker() it fails to build, citing the origin being the problem. This seems to be an issue on both Firefox and Chrome. Check it out for yourself, and my workaround, here: http://jsfiddle.net/5ag42hb1/11/
Is this not odd behaviour? Mozilla docs say that Web Workers must obey same-origin policy and to use CORS to allow cross-origin access.
The fiddle has a workaround of storing the file in a blob and passing that to the worker instead. It seems less than ideal though, introducing a lot of unnecessary complexity. Can anyone think of a cleaner solution? Is there a good channel to get this implemented properly?
I did a lot of digging and asked around on IRC channels. I got some pretty good answers thanks to the guys in #developers on the Mozilla network. Hopefully this will help anyone in the same situation as me.
To sum it up, the HTML spec outlines that running new Worker('http://remoteorigin.com/worker.js') should execute the worker with the remote origin's security context. Something that's like CORS but not quite because it's execution rights instead of reading rights.
So why isn't that how it works right now? Because browsers haven't implemented the full spec yet. Chalk it up as something to look forward to.
Until then, there are actually 2 workarounds. I outlined the blob method above but we also can use importScripts(). If you can't modify the Worker itself, you could probably make a shell Worker that simply implements the Worker you actually want.
来源：https://stackoverflow.com/questions/25458104/can-should-html5-web-workers-use-cors-for-cross-origin