[w3c/ServiceWorker] Service Worker Subresource Filter (#1584)

We’re planning to experiment in Chrome with allowing control over what requests are intercepted by Service Worker fetch events. At Facebook, the overhead introduced by Service Worker fetch events has prevented us from being able to leverage them widely. We suspect an API that allows control over which requests are intercepted would unblock us from using them.

While a robust API that allows for expression of complex conditions for determining which requests are intercepted is desirable, such an API requires significant effort to implement. We’d like to experiment with a simple API first to verify that an API with this functionality will be worthwhile. If the experiment indicates that an API of this nature would be valuable, we will then move forward with implementing the API in a more robust form.

We plan to do this with an HTTP header, “Service-Worker-Subresource-Filter”, set on the document. A similar idea has been discussed (https://github.com/w3c/ServiceWorker/issues/1454) that used relative paths as the value of the header. In the discussion, it became evident that even this approach had significant complexity. Instead, we’re proposing having the filter be represented by URL fragment. Requests with a URL fragment containing the header’s value will be the only requests intercepted by the Service Worker. For example, a document with an HTTP header Service-Worker-Subresource-Filter: foo would allow any requests with “foo” somewhere in the fragment section of the URL to be intercepted, but no other requests. When the header is not set, Service Workers will intercept all requests, as normal. 

cc: @mfalken, @n8schloss 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1584