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