Service Worker subresource filter

[noahlemen]

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): Service Worker Subresource Filter w3c/ServiceWorker#1584
• GitHub repo (if you prefer feedback filed there): A way to specify a pattern of destination URLs to hit/skip SW w3c/ServiceWorker#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 Service Worker Subresource Filter w3c/ServiceWorker#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 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 A way to specify a pattern of destination URLs to hit/skip SW w3c/ServiceWorker#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

[plinss]

@ylafon and I looked at this in today's breakout session. This seems too early for a TAG review. Please ping us (or file a new review request) once this gets more developed.

Our first-glance feedback is that filtering based on URL fragments does not seem like a viable approach, and we question the use of HTTP headers rather than augmenting the existing scoping mechanism used during Service Worker registration.