[w3ctag/design-reviews] Service Worker subresource filter (#630)

Ya ya yawm TAG!

I'm requesting a TAG review of Service Worker subresource filter.

Service Worker fetch events are currently all-or-nothing – if a Service Worker with a fetch event is registered, all fetches will be intercepted by it. This makes incremental adoption difficult because it subjects all requests to the overhead introduced by the Service Worker even if it doesn't end up handling the request in any meaningful way. A subresource filter will allow a document to specify what subresources are allowed to be intercepted by the Service Worker.

* Explainer¹ (minimally containing user needs and example code): https://github.com/w3c/ServiceWorker/issues/1584

* GitHub repo (if you prefer feedback filed there): https://github.com/w3c/ServiceWorker/issues/1454

* Primary contacts (and their relationship to the specification):
    * Noah Lemen (@noahlemen), Facebook
    * Matt Falkenhagen (@mfalken), Google
* Organization/project driving the design: Facebook, Google
* External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/6015753541124096


Further details:

* Major unresolved issues with or opposition to this design:
    * As discussed in https://github.com/w3c/ServiceWorker/issues/1584, the current implementation utilizing URL fragments is not ideal long term. It is enough to perform an experiment using [Chrome’s origin trial framework](https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md) to collect data to gauge whether work towards a more robust API will be worthwhile, but long-term the version of the API using relative and absolute URLs discussed in https://github.com/w3c/ServiceWorker/issues/1454 seems to be preferable.
* This work is being funded by: Facebook

You should also know that...

* We’re interested in conducting an origin trial with the minimal fragment-based version of the API. If the performance data from that trial is positive, then we’d like to move forward with implementing a broader API with more sophisticated URL matching
    * For Facebook, this feature is significantly easier to make use of with fragments, so we’d really like to have the final API still support filtering by fragment.


We'd prefer the TAG provide feedback as (please delete all but the desired option):

  💬 leave review feedback as a *comment in this issue* and @-notify @noahlemen


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/630