- From: Jake Archibald <notifications@github.com>
- Date: Mon, 25 Jul 2016 06:03:07 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/909/234946786@github.com>
> To keep my app as snappy as possible, I'm trying to use a cache first strategy. (To be more accurate I'm using a Promise.race, so really it's a 'fastest' strategy, but that results in the same thing practically). You need to be careful with this. `Promise.race` takes the first settled state, so a rejecting promise will "beat" a fulfilling one. See https://jakearchibald.com/2014/offline-cookbook/#cache-network-race for a better race implementation. > I do something similar and figured I would just not cache the response if it's a 302. But clearly that doesn't work, because I dont actually see the 302 in my fetch response, since it's a opaquaredirect You could check for `response.type == 'opaqueredirect'`. > The linked bugs talk about manual redirects, and event.default() `event.default()` is dead, we don't need it anymore. > Can the SW handle redirects and decide what to cache / ignore? `cache.addAll` won't cache !ok responses, but it will cache redirects. With `cache.put` you can cache whatever you want. > Most examples talk about not using production quality caching strategies, something which is left as an exercise for the reader. What do you mean by this? Does https://jakearchibald.com/2016/caching-best-practices/ help? > I appreciate caching authenticated resources is a bit of a can of worms. I suspect I'll need to clear the cache on logout. And similarly (in case the user logout via a different tab/browser/whatever without my SW getting involved Or key your cache names (and other storage) on the user name. That way you can support multiple logged in users. Of course, if the expectation is that data should be cleared on logout, you should clear data. https://w3c.github.io/webappsec-clear-site-data/ is being developed for this. > PPS. I'm running on Mac 50.0.2661.102 (Official Build) (64-bit) and it seems like the dev console often gets it's knickers in a twist wrt requests. Chrome bugs can be reported at crbug.com, but check in Canary first. If they've already been fixed, no need to report them. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/909#issuecomment-234946786
Received on Monday, 25 July 2016 13:03:41 UTC