XHRs initiated from a web worker that was created using a BLOB url ends up sending the wrong origin header

Issue #6393990 • Assigned to Scott W.


Feb 1, 2016
This issue is public.
Reported by 3 people

Sign in to watch or report this issue.

Steps to reproduce


Repro Steps:

Expected Results:

ORIGIN request header set correctly to the actual location origin.
Request headers match other browsers like Chrome and Firefox.

Actual Results:

Dev Channel specific:



0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Mara P.”

      Changed Assigned To to “Venkat K.”

      Changed Assigned To from “Venkat K.” to “Steve B.”

    • Description wasn’t copied over from old ticket:

      Lets say we are using a library that uses web workers, and we are working cross domain.
      In order for a web worker to work off a cross domain script one has to use blobs as follows (the example below uses PDF.js that has a web worker which can make XHRs)

          .then((response) => response.blob())
          .then((pdfWorkerBlob) => {
              workerUrl = URL.createObjectURL(pdfWorkerBlob);
              // Do something with the worker url. For PDF.js it will make XHR requests to fetch PDF content.

      If the worker now makes cross domain XHR requests of its own, the ORIGIN request header for that XHR is set to blob:// for IE10, IE11 and Edge.
      In all other browsers the ORIGIN header is correctly set to the window.location.origin of the web page that actually created the blob.
      As a result, servers that don’t white list Access-Control-Allow-Origin to * fail this request. blob:// is also just too generic like * to whitelist for CORS.

    • Microsoft Edge Team

      Changed Assigned To from “Steve B.” to “Scott W.”

      Changed Assigned To from “Scott W.” to “Steven K.”

      Changed Assigned To from “Steven K.” to “Scott W.”

    You need to sign in to your Microsoft account to add a comment.

    Sign in