Re: [w3c/ServiceWorker] SharedWorker script interception after redirects (#1289)

Thanks wanderview. I agree the desired behavior is to intercept each redirect and for the self.location to reflect the final URL (regardless of service workers), and probably the spec needs fixing.

Testing https://sw-shared-worker.glitch.me/ on Firefox Nightly 61.0a1 (2018-03-19) seems to show the redirect bug still occurs. The shared worker script is served from network, but the service worker still controls fetch() from the shared worker.

Test by clicking Register, then Start, then Ping. The shared worker code is basically:
```
  port.addEventListener('message', function(e) {
    port.postMessage('hello from shared worker: ' + self.location);
    fetch('/hello').then(r => r.text()).then(result => port.postMessage('fetched: ' + result));
  });
```

If it's from the network, with "SERVED by the sw" added to the first message if it's from the service worker. The second message indicates whether the fetch() was intercepted by the service worker (it says "hello from service worker" or "hello from server").

Chrome output:
```
msg from worker: hello from shared worker SERVED by the sw: https://sw-shared-worker.glitch.me/redirect
msg from worker: fetched: hello from the service worker
```

Firefox output:
```
msg from worker: hello from shared worker: https://sw-shared-worker.glitch.me/sw-controlled/shared-worker.js
msg from worker: fetched: hello from the service worker
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1289#issuecomment-374437456