[w3c/ServiceWorker] clientId on ForeignFetchEvents (#1017)

I'd like to request that `ForeignFetchEvent`s provide a `clientId` property like `FetchEvent`s do.

### Background

Our ["App"](https://github.com/ampproject/amphtml) breaks code into several javascript files, a "core" script and a series of extensions. Each script has a uses a long-cached, fingerprinted URL that allows us to identify. Every week, we publish new scripts (keeping the old) at the new fingerprint URL. All pages are then updated to use the new script URLs.

To speed up the first request after we publish, we've implemented a Service Worker that follows a "stale-while-revalidate" model. When we request script `/[this weeks fingerprint]/extension.js`, we'll check to see if we have a previous release's `extension.js` cached. If so, we'll take two steps:

1. Version lock this client to the previous release
  - This ensures the next request by the client will serve the exact same version
2. Request the new JS in the background, updating cache

This works extremely well for the normal Fetch case. All requests start by requesting the latest version, SW determine the version to serve and gives cached responses using a uniform version, and the SW requests all the new scripts in the background.

Now, our "app" works both on our own domain, and on an arbitrary publisher's domain. To give the same speed boost after publish, we'd like to implement the same stale-while-revalidate behavior. Foreign Fetch, however, has does not provide a `clientId`, so we're unable to uniquely identify which client is issuing a request. And if we can't identify the client, we can't determine if the client is version locked by a previous week's cached script.

### Temporary Solution

In the meantime, we've taken to using a combination of the request's `referrer` and a 60 second "batch" timer. All requests made by the referrer within those 60 seconds get the same "clientId". Once those 60 seconds have expired, a new id is generated.

While this'll work for now, it's far from perfect. If the publisher's page uses a `<meta name="referrer" content="none">` tag, our fallback is useless for uniquely identifying. Or, if something happens and the next script request comes after the 60 second batch, we run the risk of serving a nonuniform version.

### Real Solution

Providing a unique `clientId` like the one on `FetchEvent`s would solve this problem completely. As the string is supposed to be opaque and transient, it shouldn't have any privacy issues.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1017