- From: Ben Kelly <notifications@github.com>
- Date: Fri, 16 Dec 2016 07:49:40 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1031@github.com>
I'm looking at implementing the new Client semantics including "reserved Client" for navigations. I'm curious, though, if the current spec works as intended for redirects. Consider: 0. Register service workers at https://foo.com/ and https://bar.com/ 1. Browser navigates a new tab to https://foo.com/a 2. https://foo.com/a is intercepted by the foo.com SW and passed through to the network 3. https://foo.com/a redirects to https://foo.com/b 4. https://foo.com/b is intercepted by the foo.com SW and passed through to the network 5. https://foo.com/b redirects to https://bar.com 6. https://bar.com is intercepted by the bar.com SW Per the current spec: * The FetchEvents in steps (2), (4), and (6) will all have the same reservedClientId. * In steps (2), (4), and (6) the reserved Client.url will be https://foo.com/a (the original URL) * The foo.com SW in steps (2) and (4) can `postMessage()` to the Client which is ultimately in the bar.com origin The `postMessage()` behavior seems like a clear SOP violation and should be fixed. We could do this by either: 1. When a redirect crosses origin boundaries clear any pending `postMessage()` events on the reserved Client. 2. When a redirect crosses origin boundaries create a new reserved Client. 3. Create a new reserved Client on every redirect. I personally lean towards creating a new reserved Client on every redirect. This would also ensure the `Client.url` matches the actual final URL loaded in the window. It also seems conceptually consistent with an algorithm that uses manual redirection and re-enters the service worker each time. It also simplifies edge cases for the service worker code. It doesn't have to worry about possibly having a reserved Client `postMessage()`'d by two different service workers or twice by the same service worker by accident. Thoughts? @jungkees @jakearchibald -- 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/1031
Received on Friday, 16 December 2016 15:50:14 UTC