Service Worker Subresource Filter

[noahlemen]

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 (#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

[mfalken]

Hi Noah, thanks for starting the issue. If I understand correctly then, this is essentially issue #1454 but with a different API that specifies the URL fragment instead of the URL path or relative URLs.

I spoke briefly with @jakearchibald and using the fragment section only indeed seemed hacky. I just want to confirm how attached you are to the fragment solution. Is this part of the envisioned final API form, or is it intended as a temporary workaround to avoid the complexities of issue #1454 for the purpose of getting an experiment started via Chrome's origin trial framework to gather performance data?

[noahlemen]

Yes, your understanding is correct.

It's not something we're attached to, and definitely not the envisioned final API form. This was just the minimum we determined we'd need to conduct the experiment. I agree it seems hacky.

Perhaps there's another way we could approach this while keeping complexity minimal with a somehow pared down version of the URL path or relative URLs?

[mfalken]

Thanks, I see. So perhaps this issue can be scoped to the API offered in the origin trial, whose purpose is to get perf data and not to preview an API that we plan to spec/ship. And discussion for the API that we intend to spec/ship can continue on issue #1454.

Would you be willing to start the TAG review for this area of work as suggested in the blink-dev thread?

[noahlemen]

That sounds good to me. Yes, I'll get the TAG review started for this.

[mfalken]

Spoke with @jakearchibald. We are OK with going ahead with an experiment using this Service-Worker-Subresource-Filter header with fragments in order to gather performance data only. The actual shipping API if we do ship will possibly be different from this one.

[ArthurSonzogni]

Out of curiosity. A question that came up during OWP security meeting (@mikewest). Can this header be delivered via HTML tag?
We don't really see how this could be used harmfully, but if this isn't supported, then that's even simpler.

[noahlemen]

No, this cannot currently be delivered via HTML tag.

[noahlemen]

Unfortunately, we did not observe any significant difference in performance on facebook.com between users with Service Worker subresource filter and those without. We observed various regressions in both groups versus the control (without any sort of Service Worker caching). We’re concluding that although it may be possible that the feature has some performance impact, it is too marginal for us to observe so we cannot prioritize further work in this area.