noah...@fb.com, fal...@chromium.org
https://github.com/w3c/ServiceWorker/issues/1584
https://github.com/w3c/ServiceWorker/issues/1584
Allows control over what requests are intercepted by Service Worker fetch events. By setting a Service-Worker-Subresource-Filter HTTP header on the document to some string, only requests which contain a fragment containing the value of the header string will be intercepted. When not set, Service Workers will intercept all requests, as normal.
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.
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.
https://github.com/w3c/ServiceWorker/issues/1584
None
Pending
None
Gecko: No signal
WebKit: No signal
Web developers: Facebook is interested
No
None
https://bugs.chromium.org/p/chromium/issues/detail?id=1202160
https://www.chromestatus.com/feature/6015753541124096
This intent message was generated by Chrome Platform Status.
Contact emails
noah...@fb.com, fal...@chromium.org
Explainer
https://github.com/w3c/ServiceWorker/issues/1584
Specification
https://github.com/w3c/ServiceWorker/issues/1584
Summary
Allows control over what requests are intercepted by Service Worker fetch events. By setting a Service-Worker-Subresource-Filter HTTP header on the document to some string, only requests which contain a fragment containing the value of the header string will be intercepted. When not set, Service Workers will intercept all requests, as normal.
Blink component
Motivation
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.
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.
Initial public proposal
https://github.com/w3c/ServiceWorker/issues/1584
TAG review
None
TAG review status
Pending
Risks
Interoperability and Compatibility
None
Gecko: No signal
WebKit: No signal
Web developers: Facebook is interested
Is this feature fully tested by web-platform-tests?
No
Flag name
None
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1202160
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6015753541124096
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR15MB351940CCC51BF06C5DCD17FFD6459%40MN2PR15MB3519.namprd15.prod.outlook.com.