Consider a package located at URL P that contains 2 resources A and B identified by fragment identifiers #A and #B. If a web page URL uses P#A or P#B, it might be interesting to avoid downloading the entire package when only a small part is needed, or at least to prioritize the download for the parts of the resource being used in the fragment. I’m thinking that such processing could be done in a Service Worker that understands the package format, but unfortunately it cannot at the moment.
Service Workers are meant to behave as a client-side, browser-integrated proxy. As such, they do not receive fragment identifiers in the requested URL of fetch events. However, since a Service Worker is a specific kind of proxy (hey it runs in a browser), I’m wondering if it wouldn’t be interesting to let fragments reach Service Workers. Any thought here ?
2 thoughts on “Service Workers, packages and fragment identifiers”
Certainly an interesting idea to allow the fragment identifiers to be passed through to the service worker. What would be the benefit of this over appending a normal URL parameter? Maybe seamless fallback without affecting caching of the asset?
I can think of some scenarios where it would be interesting to use this as an inline communication method with your service worker, but most of that could be done with URL parameters and then having your service worker strip those parameters.
Actually, since my post, I raised an issue on the spec and the proposal was agreed see https://github.com/slightlyoff/ServiceWorker/issues/854. Fragment identifiers have a standard syntax that is well defined based on the MIME type of the resource. Using general URL parameters would work but be less interoperable I think.