Relaying service worker state when serving Clear-Site-Data

[asakusuma]

The Problem

When applying Clear-Site-Data (CSD) for the purpose of removing a specific service worker, it's important to only apply CSD where absolutely necessary, since there will typically be some collateral damage (CSD removes all DOM storage API data and all other service worker registrations for the entire domain). Additionally, there are many scenarios in which only a subset of service workers in the wild need to be removed. Ideally, service workers that do not need to be removed should keep working as normal.

In practice, the server often needs to know about client state in order to make a decision on whether or not to apply CSD. For instance, the server might want to only apply CSD to a particular version of the service worker. The service worker script itself is, in theory, a great place to serve CSD when necessary, since updates to the service worker require fetching the script. Unfortunately, there is currently no good way for the responding server to know which version of the registration is actually active. Etag/If-None-Match can be used to inform the server of the last script version that was seen by the browser, but the last seen version is not necessarily the same thing as the active version.

Current Work Around

To work around this issue, we added a new server endpoint expressly for the purpose of delivering CSD to a service worker. The controlling/active service worker calls this endpoint on every "index.html" request, passing in it's version. This is less than ideal for 2 reasons:

1. Requires an extra request/isn't part of the normal update/script request lifecycle
2. Requires the service worker to do something correctly to "audit" itself

Straw man 1st Class API

To better support this use case, we could add a request/response header combination for the script request/response, much like ETag/If-None-Match. For instance, the script response could include the header SERVICE_WORKER_TAG: 1.2.0. Once that particular script is materialized into an active version, requests for a new worker script would include the request header ACTIVE_WORKER_TAG: 1.2.0. In this example, we use a version string, but the contents are opaque, it can be any string value.

[asutherland]

@asakusuma Is there a reason the existing navigation preload mechanism can't be used for this? Assuming the script knows its own version, it can update the header value during its activation or installation (or both).

[asakusuma]

@asutherland hadn't thought about that approach, sounds better than making a completely new request to check for CSD. Seems like it would work, although it still doesn't address isn't part of the normal update/script request lifecycle. I believe it solves most of the Requires the service worker to do something correctly to "audit" itself, since if the server expects a version in the Service-Worker-Navigation-Preload header, it can default to serve CSD if the service worker doesn't send it.