- From: Ben Kelly <notifications@github.com>
- Date: Thu, 01 Feb 2018 15:21:42 +0000 (UTC)
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 1 February 2018 15:22:34 UTC
> If this is the case, dropping resultingClientId in favor of having clientId represent either a subresource request's client or a non-subresource request's client can be an option I guess. I don't think we should try to merge the properties back together. They are semantically different and it doesn't cost anything to have two properties. My inclination is to probably implement resultingClientId and keep navigation clientId empty at first. Also note, exposing the clientId on navigations is a bit like referrer restricted to same-origin. It should probably respect the referrer policy. If the policy is set to `no-referrer` then I don't think we should ever set a navigation `FetchEvent.clientId`. -- 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/1267#issuecomment-362298501
Received on Thursday, 1 February 2018 15:22:34 UTC