A header-based SW installation

[jungkees]

It's been discussed as part of the navigator.connect() and decided to be proposed as an extension to SW API (v2).

Assuming a communication between a client SW and a service SW is enabled through the efforts in navigator.connect()'s persistent channel messaging and the fallThrough requests proposal, the client SWs would need to use readily installed service SWs whenever possible.

Here's a proposal to allow services to install their SWs using HTTP headers when any of their resources are requested: https://github.com/mkruisselbrink/navigator-connect/blob/gh-pages/explainer.md#mommy-where-do-service-workers-come-from

[jakearchibald]

On #684 I pitch the idea of:

// https://foo/sw.js
self.oninstall = event => {
  event.waitUntil(
    event.registerExternal('//font-service/sw.js')
  );
};

This would only require '//font-service/sw.js to have a header indicating scope. It doesn't allow page/subresource headers to register a ServiceWorker, but is there any benefit in doing this?

[mkruisselbrink]

I don't really like the idea of having in this case the foo service worker specify the exact path to the font-service service worker script. It seems to me that conceptually the script URL of a service worker should be an implementation detail of that site, and not part of its public API. But maybe that's just my mental model being wrong.

And specifically for the fonts usecase, allowing subresource headers to register a ServiceWorker is what makes this all work transparently. I'm not entirely sure what we would gain by requiring any website that wants to benefit from a fonts service worker to explicitly specify this. Shouldn't websites that don't have their own service worker also be able to benefit from services they rely on having service workers?

[jakearchibald]

allowing subresource headers to register a ServiceWorker is what makes this all work transparently

I don't think it does. Your site should work offline after install. Since font requests happen when the font is requested, you could end up with a serviceworker installing without a request to the font service.

Shouldn't websites that don't have their own service worker also be able to benefit from services they rely on having service workers?

Hmm, yeah, that would be nice.

[KenjiBaheux]

@jungkees I lost track of this feature. Was there any other relevant discussion or pushback?

We are discussing with partners and for some a header based SW installation is a must have (e.g. Google Fonts: not a destination website, integration point being a link rel stylesheet)

[jungkees]

I think it has just not been discussed for a while. I added this issue to the f2f agenda. If there's not enough time to cover this, I'll at least share it with the attendees so we can follow up on the discussion.

[jakearchibald]

F2F:

Header: Link: </sw.js>; rel=serviceworker; scope=/
But also element: <link rel="serviceworker" scope="/" href="/sw.js">

[ehsan]

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1243404

[mkruisselbrink]

@annevk How would I go about actually spec-ing this?

The <link rel= part is probably relatively straight forward. Similar to how specs like the web app manifest specified a new link type, we can do the same in the service worker spec for the new serviceworker link type. Although I'm not sure how we'd add the new 'scope' attribute to the link tag without changing the HTML spec directly?

But what do we do about the Link header. https://www.w3.org/wiki/LinkHeader makes it sound like it isn't actually specified anywhere (other than some old version of HTTP 1.1). So how/where should Link be specified?

[KenjiBaheux]

Perhaps, following how it's done for preload would work?
http://w3c.github.io/preload/
cc/ @igrigorik