Re: [ServiceWorker] Support module service workers, and update for ES6 (#831)

I worked on this today and got stuck. The problem is, what do we do in the following situation:

```html
<script type="module" src="sw.js"></script>

<script>
navigator.serviceWorker.register("sw.js", { type: "module" });
</script>
```

Currently, all module loads go through the module map, which explicitly makes sure that we only fetch them once. Because of this, the special preprocessing steps on the request and postprocessing steps on the response do not happen. That seems pretty bad.

I wanted to check what the desired behavior here was for the above example. I think we need to re-fetch `sw.js`, with appropriate modifications to the request (request's destination to "serviceworker", skip service worker flag, redirect mode to "manual", set a special header Service-Worker/script, and set request's cache mode to "reload" under certain conditions). And check the response similarly (cache state, MIME type, and Service-Worker-Allowed header).

There is another related example:

```html
<script>
navigator.serviceWorker.register("sw.js", { type: "module" });
</script>

<script type="module" src="sw.js"></script>
```

There are two possible behaviors here IMO:

- If sw.js is a valid module but not a valid service worker (e.g. because of the Service-Worker-Allowed header), it still runs as a module and ends up in the module map.
- If sw.js is a valid module but not a valid service worker, the failure to load it as a service worker means it will never load as a module.

I think the first of these choices is better.

What this essentially means is that the initial fetch needs to be decoupled from the module map.

Since this is pretty tied in to HTML, I think I will try again but this time doing all the extra work in HTML. I will report back on how it goes. Maybe HTML will need to grow "to fetch a service worker module script tree".

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/831#issuecomment-189046699

Received on Friday, 26 February 2016 00:10:20 UTC