[w3c/ServiceWorker] Proposal: clientURL property on FetchEvent (#1532)

I have a use case for a new property, `clientURL`, being added to the [`FetchEvent` interface](https://w3c.github.io/ServiceWorker/#fetchevent-interface).

In scenarios in which a `FetchEvent`'s `clientId` is populated (including subresource requests), `clientURL` would be set to a URL string representing the client's current location. In scenarios in which `clientId` is not populated, it would be set to an empty string.

I would like to use this client URL information as part of an advanced routing option in the [Workbox](https://developers.google.com/web/tools/workbox/) service worker framework—basically, to allow developers to opt-in to different routing and caching rules for subresource requests that originate from different logical sections of their web app, all from within the same registered service worker instance. In order to accomplish this, I need to obtain the client's **full** URL **synchronously**, so that within the `fetch` handler that Workbox sets up, a synchronous decision can be made about whether or not to call `respondWith()` on the `FetchEvent`.

There are some alternatives to creating a new property that rely on existing functionality, but neither is appropriate for my use case:

- Similar information is already exposed synchronously via the `request.referrer` property of a `FetchEvent` when a lax [`Referrer-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) is in effect, but when a more restrictive policy is in place, `request.referrer` may not contain the full URL.

- Similar information is already exposed asynchronously by passing the `clientId` of a `FetchEvent` to [`clients.get()`](https://w3c.github.io/ServiceWorker/#dom-clients-get), and then obtaining the location of that return value.

-- 
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/1532