Re: [w3c/ServiceWorker] reserved Client objects and redirected navigations (#1031)

To summarize, we have three options here:

1. Use new clients for each redirect (and so each registration matching)
  - Seems no corner case
  - Can't retain all the messages targeted to the intermediary clients; only the last environment can hold the queued messages
2. Use a single client throughout redirects
  - Override request's url for each entry to main fetch
  - Basically queue messages to the environment, but to avoid SOP violation, when crossing an origin boundary, the messages queued in the environment should be flushed before invoking main fetch
  - Depending on the location urls, multiple SWs with different scopes can `postMessage()` to the same client. This means devs may have to control the received messages in the application level.
3. Create a new client when crossing origin boundaries
  - Best of both worlds (or worst of?)

1 seems the simplest. 3 seems good in the sense that a single reserved client represents what becomes the actual client at the end regardless of which location urls are encountered. For 2 and 3, the fact that client:scope can be 1:N bothers me.

-- 
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#issuecomment-268475751