demo · v140

SW Fetch Interception

The most concrete consequence of the spec fix: a fetch() from inside a blob-URL SharedWorker now goes through the page's service worker, so cache, offline support, and synthetic responses all apply. Pre-140 the request bypassed the SW entirely. Side-by-side request flow plus a live probe of this browser's behaviour.

pre-140 — request bypasses SW

page → SW for page.html
↓ new SharedWorker(blob:…)
SharedWorker.fetch("/api/x")
→ straight to network
(SW never sees it)

Chrome 140 — full SW participation

page → SW for page.html
↓ new SharedWorker(blob:…)
SharedWorker.fetch("/api/x")
→ SW
(cache, offline, mock — all apply)
probing…

Click "test blob SW fetch" to instantiate a blob-URL SharedWorker and watch its fetch route.

// page is controlled by /sw.js
const blobSrc = `
  onconnect = (e) => {
    const port = e.ports[0];
    port.start();
    fetch("/api/whoami")
      .then(r => r.headers.get("x-served-by"))
      .then(s => port.postMessage({ servedBy: s }));
  };
`;
const w = new SharedWorker(URL.createObjectURL(new Blob([blobSrc], {type: "application/javascript"})));
// Chrome 140+: /api/whoami goes through the page's SW; x-served-by may say "sw-cache".
// pre-140: bypasses the SW entirely; x-served-by reflects whatever the origin server set.

see also