Intent to Implement: Link rel=serviceworker
Marijn Kruisselbrink
Contact emails
m...@chromium.org, bsit...@chromium.org, kenji...@chromium.org
Spec
https://github.com/slightlyoff/ServiceWorker/pull/828 (also http://mkruisselbrink.github.io/ServiceWorker/spec/service_worker/#link-type-serviceworker)
Summary
Add support for LINK rel=serviceworker as an element and header to allow the installation of a Service Worker declarative in a document or via a header.
Motivation
The primary motivation is that this allows a service worker that wants to handle foreign fetch events to bootstrap themselves. A server can respond to a request that it would like to handle via foreign fetch with a response including this new Link: header to install a service worker. Once installation is complete future requests for the same resource can then be intercepted by the service worker.
But even outside of foreign fetch both the declarative way via the link tag to install a service worker, and a way for a server to install a service worker using a header give people more options for the way they can add service workers to their existing websites.
Interoperability and Compatibility Risk
This feature is the result of collaboration with other browser vendors, and in particular was discussed at the last Service Worker face-to-face meeting. Certainly mozilla seemed supportive of the idea (and they have a bug to implement this as well).
When the new link type is used on top-level documents (or as link tag in a document) the feature doesn't expose any new capabilities, it just provides a different way to achieve something you can already do today. As such I don't think that part has any risks that the existing serviceworker.register() API doesn't already have.
Allowing requests for subresources to install service workers is maybe a bit more risky, and as such it probably makes sense to initially ship this behind the experimental framework (together with foreign fetch). That way we'll be able to get real world data and make sure that this feature actually is what we want, and we haven't missed any potential problems.
Ongoing technical constraints
Likely none, although there might be some code duplication since currently all Link: header parsing is done in blink, and it is likely for this feature we might want to do this in the browser process. See also this design doc.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5682681044008960
Requesting approval to ship?
No.