Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

Jake's cookie suggestion definitely makes a lot of sense to me.  At least in Gecko, cookies are synchronously available just like SW registrations.  They're also a known quantity, although things like limits do vary between browsers.  And creating a less wacky API to manipulate them would be a great thing for everyone.  It also avoids creating another separately managed per-TLD+1 hunk of (potentially) persistent memory.  Sites get the same (memory) budget they had before with the same latency characteristics.

The one downside is that without some specialization, this would end up being a "it will work most of the time" thing.  In addition to the SW-specific-cookies-not-deleted-on-unregister case @n8schloss pointed out, there's also the issue that cookies are subject to eviction due to browser-wide cookie limits and per-TLD+1 base domain limits.  The required specialization seems like it would be a major hack/monkeypatch not particularly justified by this use-case.  For example, we could treat a cookie with the path of the SW itself as magic so that it gets deleted on `unregister` and it is pinned so it doesn't get evicted by standard eviction logic.

The argument for leaving cookies as they are is that:
- At least for Gecko, cookie eviction occurs based on last access and global eviction happens very infrequently (~every 30 days), so an impacted SW would likely be for a rarely visited site/path where arguably the SW itself might also be appropriate to nuke.
- If the cookie needs to be more than a boolean indicator, the cookie should end up being set regularly anyways.  Plus, the no-cookie-because-it-got-evicted case is also roughly equivalent to the first-install case.

-- 
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/920#issuecomment-247018664