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

> A cross-origin script is not allowed and such URL should have been already filtered out (in Register step 2) before invoking fetch a classic worker script and fetch a module script tree.

Hmm, does this properly take care of a same-origin request URL redirecting to a cross-origin response URL? I guess maybe that is why you are setting the redirect mode to manual?

> For both fetch a classic worker script and fetch a module script tree, SW wants:

Thanks for outlining these. Hmm, this seems pretty tricky.

At first I thought it would be better for the SW spec to define`fetch a classic service worker script` and `fetch a module service worker script tree` by copying the algorithms from HTML and then inserting the appropriate steps and changes. But then I realized that the changes will also need to modify "fetch a single module script" for the response stuff, which makes that probably not a good idea.

How about the following changes to HTML:

- "fetch a classic worker script" replaces _is shared_ with _destination_.
  - If _destination_ is "serviceworker", then either HTML or Fetch sets the redirect mode and `Service-Worker`/`script` header. @annevk, any reason not to have Fetch do this?
- "fetch a classic worker script" and "fetch a module script tree" get an additional optional _cache mode_ parameter. You can then set this under the appropriate conditions.
- We also add _destination_ to "fetch a module script tree". The fact that it is currently not present seems like a bug (we currently always set the destination to "subresource" even for module workers. It looks like "subresource" doesn't even exist anymore?)
- We add the checks for cache state, MIME type, and Service-Worker-Allowed in one of two ways:
  - Either HTML's "fetch a classic worker script" and "fetch a single module script" check them if _destination_ is "serviceworker", or
  - Fetch adds these checks itself. @annevk, any reason not to make these intrinsic properties of fetching a service worker?

An alternative design would be:

- We still do _destination_ for both algorithms. But, we don't do any special processing, in either Fetch or HTML, based on destination.
- We add "set up the request" and "process the response" hooks to the two algorithms. Then the SW spec would do all its special stuff in these hooks.

Also, I assume that we don't want to apply any of these customizations to `import`-ed files from the service worker? Or... do those need different customizations, like [importScripts](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#importscripts-method)??

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

Received on Monday, 22 February 2016 19:20:26 UTC