SharedWorker script interception after redirects

Suppose '/redirect' redirects to '/in-scope/shared-worker.js', and the page does new SharedWorker('/redirect'). And there is a service worker with scope 'in-scope'.

In Chrome today, you end up with a shared worker script served by the service worker.

In Firefox today, you end up with a shared worker script served from network from 'in-scope/shared-worker.js' .

Also, subresource requests from the shared worker are intercepted by the service worker for both browsers. So I think the implementation intent is for the initial request and each redirect to look up the appropriate service worker to intercept that URL, and finally to make the SharedWorker client be controlled if the final URL was in-scope.

I have a basic test at https://sw-shared-worker.glitch.me/ showing this.

Somewhat related, self.location in Chrome is 'redirect' and 'in-scope/shared-worker.js' in Firefox.

The spec seems to say to intercept only for the initial request URL, because service worker registration matching is based on "Creation URL" in 2.4 Selection and Use: "That is, the service worker client attempts to consult a service worker registration whose scope url matches its creation URL." Creation URL is a concept from HTML. It looks like Creation URL is set at set up a worker environment settings object, which is called from "run a worker" in Step 9, which is before any network fetch which happens in Step 13.

I've not really tested other redirect hooks like AppCache.

I was looking at this for our new "servicified" service worker architecture. I'm not very motivated to invest a lot of time in this since Shared Workers don't have much usage or browser support, but will try to implement something reasonable.

Start with the linked SharedWorker reproduction and compare its redirect behavior in Chrome and Firefox. Read the Service Worker selection and use section and HTML's creation URL and worker environment setup sections, then determine the intended interception and client-control behavior. Done means the specification and relevant implementations or tests agree on redirects and the final URL.