Intent to Prototype: Service Worker subresource filter

120 views
Skip to first unread message

Noah Lemen

unread,
Apr 23, 2021, 12:31:59 PM4/23/21
to blin...@chromium.org

Contact emails

noah...@fb.comfal...@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

Blink>ServiceWorker

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.

 

Yoav Weiss

unread,
Apr 26, 2021, 7:18:23 AM4/26/21
to Noah Lemen, blin...@chromium.org
On Fri, Apr 23, 2021 at 6:31 PM 'Noah Lemen' via blink-dev <blin...@chromium.org> wrote:

Contact emails

noah...@fb.comfal...@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

Blink>ServiceWorker

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

Once the discussion with the SW WG (on the above issue) settles, it might be worthwhile for y'all to file an "Early design review" with the TAG to get their opinions on this problem space and your solution early.



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.
Reply all
Reply to author
Forward
0 new messages