-
Notifications
You must be signed in to change notification settings - Fork 19
Description
I’m using web-demuxer inside a Web Worker.
Both my page and my worker are served from:
However, when I initialize WebDemuxer inside the worker and host web-demuxer.wasm locally (same origin), the WASM file fails to load with a CORS error:
Access to fetch at 'https://localhost:8080/js_lib/web-demuxer.wasm'
from origin 'null' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
What’s confusing is:
My page origin is https://localhost:8080 . My worker origin is also https://localhost:8080
But the request for web-demuxer.wasm is sent from origin = null. After investigation, I found this only happens when web-demuxer.wasm is hosted locally.
If I use the default CDN path:
https://cdn.jsdelivr.net/npm/web-demuxer@latest/dist/wasm-files/web-demuxer.wasm
everything works fine.
Root cause (analysis)
It appears that this is caused by Emscripten pthread support used by web-demuxer.wasm.
Emscripten creates an internal blob worker for pthread execution. That worker always has:
origin = null
That blob worker then tries to fetch(web-demuxer.wasm). This turns the request into:
null → https://localhost:8080
Which is treated as a cross-origin request by the browser and therefore requires:
Access-Control-Allow-Origin: *
CDN hosting works because jsDelivr already sends permissive CORS headers. Local hosting fails unless the server is configured to allow origin: null.
Expected behavior
It should be possible to host web-demuxer.wasm on the same origin as the page/worker without requiring special CORS headers.
Question
Is there a way to configure web-demuxer / Emscripten runtime to: Avoid using a blob pthread worker, or Provide an external worker file URL, or Control how the WASM file is resolved/fetched so it does not originate from origin: null?
This would allow self-hosting web-demuxer.wasm without needing Access-Control-Allow-Origin: *.
Thanks!