- From: Arthur Stolyar <notifications@github.com>
- Date: Mon, 22 Aug 2016 17:31:05 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/commit/e2a6d18647b97707c7a571163eef7838f82ca611/18735235@gith>
``` > Some APIs already expose !ok to some extent, such as AppCache and <object>. If we figure out > that's fully equivalent to exposing response.ok on opaque responses, we will expose it. Then we can > make addAll work with no-cors and still reject on 404s etc. ``` I knows FB's API which returns _OK_ when user not logged and _not OK_ when logged. I don't think it makes sense to add another way to check this. > The appeal of APIs like add was that I could fetch() one or more requests, then add the result straight to the cache. Well, you can add results straight to the cache with `put()`, just write a little bit of a code. _________________________________________________ Basically, you just caught into `addAll` caching 404/500 responses. Imagine that `addAll` won't have this change and restriction and so you probably wouldn't even think that CDN may return an error and what it will be cached. But CDN **will** in some day, because of network problems, CDN down, etc. And then bad happens, your users get cached wrong response, website isn't working and ServiceWorker update doesn't help because you are probably caching static (CDN) resources in a separate cache which doesn't update (why would it, those assets are static after all). And then you probably don't know what to do, you don't know how to debug it and you are simply going to complain about ServiceWorker into the Twitter, this repo, etc. Is that better? I don't think so. -- 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/commit/e2a6d18647b97707c7a571163eef7838f82ca611#commitcomment-18735235
Received on Tuesday, 23 August 2016 00:31:47 UTC