-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross Origin pthread worker #21937
Comments
Can you explain why this doesn't work? Why cant you serve the main JS file from the CDN? We do have setting called |
I know it is cached, but it is still from cross origin. The thing that matter is the origin, not cached or not. |
Sorry I didn't read the title there. I'm not too familiar with cross-origin limitations. If you, or anyone else, has any ideas on how to make this work better that would be most welcome. |
So, to be clear, the security policy disassllows |
Trying to understand the issue, the only mention I see about same-origin restrictions in workers looks like it related to subworkers: |
Hmm ... I wonder if we could do something line Maybe you could even try this out by adding something like this to your pre-js file:
? |
I tried this locally and the following
|
Did you try to serve that file through a cdn? |
Nope, I'm just going by the fact that |
Yes, importscript in the worker seems to work fine. We should integrate this fix because I'm sure many people will use a cdn |
I'm confused by https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers though. It seems to suggest that only sub-workers have this requirement by default? So by default, using a CDN like this should work? |
Can you confirm that the |
I know it's weird, but see this: https://stackoverflow.com/questions/58098143/why-are-cross-origin-workers-blocked-and-why-is-the-workaround-ok Basically the default mode for worker URL fetching is same-origin, so a cross origin URL will fail. Importscript default is just a normal fetch, so it works |
So it sounds like maybe MDN is just wrong on this a not up-to-date with the spec, since it only mentions the same-origin requirement for sub-workers. |
Yeah it does, probably should report this to them. |
It doesn't, I'm using modularize, so in the module callback document.currentScript is null. I used the _scriptName global variable that keeps a reference to document.currentScript.src instead. It works. Normally, without modularize, it is available, but with that on, it won't. |
Can you share the full fix you came up with here? |
I took yours and replace document.currentScript.src with _scriptName for modularize mode, not sure about non-modularization
|
Does that work? Looking at the code it seems that |
(We could potentially move the |
Wait, I thought the _scriptName is declared before the iife is returned to be used in the function? |
I think MODULARIZE mode differs in this respect and injects |
PR? |
I'd like to better understand the problem, and decide if we should do this default or make it a new option. I also wonder if there is any downside to doing in the case when things are hosted on the origin. For example, does it make debugging hard / more opaque when the URL passed to For now, is it OK if you use your workaround? |
To be fair MDN kinda said it here: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker that the URL should be same origin as the host One more thing, if we decide to go with this, don't forget to set Blob's MIME type to |
@msqr1 I'm curious, are there some CDNs (e.g couldflare and fastly type things) that don't require you to do cross-origin stuff? i.e. they take over your whole domain, so to speak? I could be misunderstanding but I wonder how popular those two different types of solution are? |
There is no such CDN service that I know of. But I think Website hosting service does exactly what you say, they have servers everywhere that basically acts as CDN. Those servers serve your main page, your assets and everything else you have. You can basically treat it as your own domain while still utilizing their "CDN" to serve files fast. I don't think it would make sense for a CDN to take over your domain, because what CDN does is it helps you minimize distance by utilizing their numerous servers available around the globe (because you only have one, a small, or a few server). |
@sbc100, CSP needs to be set for worker-src or default-src to blob for the workaround to spawn the worker. But at this point, why don't we just spawn the whole worker content straight from the blob already? Why importScript if we're using blob anyway? In my opinion, if we choose to do this, I would make a new setting like CROSS_ORIGIN_PTHREAD that uses the new approach of spawning from the blob. |
It seems reasonable to add a new option for this yes. Feel tree to send a patch. BTW, I would call the option PTHREAD_CROSS_ORIGIN so that is groups with the other PTHREAD_-prefixed settings. I'm also curious to see what proportion of folks are affected by this. |
If the workaround requires worker-src or default-src already then why not use the |
You're right, I forgot about the cache |
I love the new inline worker change, but now we can't never use a 3rd-party CDN to serve those files again, because Worker construction requires the file to be in the same origin. Previously, we can just host the very small worker file on our server, while serving the heavy main file through a CDN, but now we can't anymore. Is there any way we could address this problem?
The text was updated successfully, but these errors were encountered: