Intent to Experiment: Service Worker subresource filter

[Noah Lemen]

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

Blink>ServiceWorker

 

TAG review

https://github.com/w3ctag/design-reviews/issues/630

 

TAG review status

Resolved as “too early”. TAG review to continue post-experimentation.

 

Risks

Risks are minimal as this API is not intended to be shipped as-is

 

Interoperability and Compatibility

In its current state, the API will not ship. We plan 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. The experiment is intended only for gathering performance data.

 

Gecko: No signal

 

WebKit: No signal

 

Web developers: Positive 

Facebook is interested in using this API in multiple web apps if the experiment is successful

Goals for experimentation

In this experiment, we hope to observe that using the subresource filter allows a site (in particular we’re planning to experiment on facebook.com) to cache a specified subset of its resources via a Service Worker without adding overhead to other requests. 

 

Ongoing technical constraints

None

Debuggability

Devtools Network tab correctly indicates which requests are intercepted (via the is:service-worker-intercepted filter) by the Service Worker when the subresource filter is in effect.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Feature is supported anywhere Service Workers are supported

Is this feature fully tested by web-platform-tests?

No

 

Flag name

--service-worker-subresource-filter

Requires code in //chrome?

False

 

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

 

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/uEcgVgTJ5qA

 

This intent message was generated by Chrome Platform Status.

 

 

[Yoav Weiss]

What are the desired timelines for experimentation? Are there other web properties that plan to experiment, or is Facebook the only one? 

--
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/MN2PR15MB351941F934DF3647B457CA11D6E59%40MN2PR15MB3519.namprd15.prod.outlook.com.

[Yoav Weiss]

Also, how does this effort relate to URLPattern?

[Noah Lemen]

We want to experiment from M92 to M95. Facebook is the only web property I am aware of planning to experiment with this. 

URLPattern seems like a strong option as a more permanent API shape providing this functionality in the future. In the short-term as we're only looking to collect performance data to understand the value of this functionality I'm not sure URLPattern relates yet. If the experiment is fruitful and we move forward with designing something that can ship widely, URLPattern seems like a very articulate way to express URL matching and should definitely be considered.

[Yoav Weiss]

LGTM to experiment M92-M95

On Wed, Jul 28, 2021 at 12:40 AM Noah Lemen <noah....@gmail.com> wrote:

We want to experiment from M92 to M95. Facebook is the only web property I am aware of planning to experiment with this. 

URLPattern seems like a strong option as a more permanent API shape providing this functionality in the future. In the short-term as we're only looking to collect performance data to understand the value of this functionality I'm not sure URLPattern relates yet. If the experiment is fruitful and we move forward with designing something that can ship widely, URLPattern seems like a very articulate way to express URL matching and should definitely be considered.

Makes sense!

[Noah Lemen]

We ended up needing to make more changes to support enabling the feature via origin trial: https://chromium-review.googlesource.com/c/chromium/src/+/3061699

 

It will be in 94. We will now need to change the OT timeline to M94-M97 since we cannot experiment prior to 94.

[Yoav Weiss]

That's perfectly fine. No need for an LGTM for such changes, but thanks for notifying the thread! :)