Contact emails
Engineering: m...@chromium.org, bsit...@chromium.org
Spec editor: m...@chromium.org
Spec
draft proposal: https://github.com/slightlyoff/ServiceWorker/pull/751
Summary
Foreign Fetch is a proposal to enable service composition via third party Service Workers.
Motivation
Cross-origin composition is a key feature of the web platform. Today, Service Workers enable sites to use and compose third-party resources by storing CORS Response and Opaque Response instances in caches.
These cross-origin resources are:
This leads to inefficiencies and missed opportunities.
Let’s take a look at a concrete example
For performance reasons, the major web fonts services use advanced techniques to subset their web fonts. Unfortunately, these subsets can be overly specific to a given website. This issue is exacerbated with large web fonts (e.g. CJK): dozens of overlapping-but-exclusive font subsets end up in the HTTP cache. This is clearly suboptimal: storage is wasted and the low degree of commonality of these subset negatively impact cache hit rates.
With Foreign Fetch, a website requesting a CJK font subset would trigger the corresponding third party Service Worker and allow it to reason about the request on the client side. Because of complete knowledge, such a Service Worker could intelligently manage its cache as well as update or rework the subsets (e.g. merge subsets to fulfill the request). Furthermore, these Service Worker could take advantage of Background Sync to further optimize their cache or offset non critical tasks.
Foreign fetch
We propose extensions to Service Workers that enable opt-in fall-through fetch handling as well as the ability to register a third party service worker via HTTP headers to enable such scenarios.
Compatibility Risk
Medium.
Adds new API surface to Service Worker
Requires small modifications to the spec for Fetch
Foreign Fetch is the result of an on-going collaboration with Mozilla
Ongoing technical constraints
Implementing this feature will involve adding code that runs for pretty much any network request, as such there is of course the potential for ongoing constraints. However the actual implementation will be fairly well isolated, so in reality this should not impose any ongoing technical constraints.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=540509
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5684130679357440
Requesting approval to ship?
No.