- From: Domenic Denicola <notifications@github.com>
- Date: Mon, 22 Feb 2016 11:19:56 -0800
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/831/187328875@github.com>
> 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