Re: [w3c/ServiceWorker] Eliminating SW startup latency for common case (#920)

Hmm, I'm not totally sure that this would work for us. Being able to modify this after the SW is installed is important and I think a header makes much more sense than cookies.

#### Header VS Cookie
We're going to be serving totally different responses when there is a SW present vs when there isn't. Having a header means that we can ensure that this extra info only gets added when there's an SW, using a cookie means that it'll always be sent. This can lead to some weird things if a user uninstalls an SW without deleting cookies, if browser vendors ever want to build something that skips SWs when they are being unresponsive, if SW cleanup runs into issues, etc.
Having info that can and is only added via the SW for these requests is important, cookies would not provide this but headers do.

#### Modifying After Instillation
If we go the header route then we'll likely want to change the header without updating the SW. A use case for this is if we do a code push to update Facebook, but nothing in the Service Worker code changed. In that case we may not want to push an update to the Service Worker, but we'd still want to modify the header to match what the newest version of Facebook server code is expecting. Or we may want to update the header with information about how up to date our cache of the page chrome is, etc.
If we don't go the header route, then we'll likely need to turn off preflight in cases where the active SW and Facebook server revision are out of sync and we need to add information from within the service worker before sending out requests.

-- 
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-245777469