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.
https://github.com/w3ctag/design-reviews/issues/630
Resolved as “too early”. TAG review to continue post-experimentation.
Risks are minimal as this API is not intended to be shipped as-is
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
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.
None
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.
Yes
Feature is supported anywhere Service Workers are supported
No
--service-worker-subresource-filter
False
https://bugs.chromium.org/p/chromium/issues/detail?id=1202160
https://www.chromestatus.com/feature/6015753541124096
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/uEcgVgTJ5qA
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/MN2PR15MB351941F934DF3647B457CA11D6E59%40MN2PR15MB3519.namprd15.prod.outlook.com.
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.
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.