- From: Jungkee Song <notifications@github.com>
- Date: Fri, 19 Jun 2015 08:16:19 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/361/113545874@github.com>
> For example, I don't see where the incumbent record is cleared for a fetch record when the new response body completes. It seems the old incumbent should be dropped then. Am I missing it? [addAll()](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-addAll) 6.4.2.2.1 waits until either the response's body completes or the stream's terminated. 6.4.2.2.3 replaces the old incumbent record with the successfully fetched fetching record whereas 6.4.2.2.2 performs the rollback. > can you clarify if Cache.put() is intended to implement stale-while-revalidate as well? Yes. As long as an incumbent record exists, matchAll() always returns the value even if the response argument to the `put()` method is still fetching the body. Step 14 of the `put()` method is basically doing the same thing with `addAll()`. > Actually, that same quote is used for addAll() as well as put(). This is intended as addAll() and put() both deal with the fetching response object. > That suggests to me that we will wait for new the newly inserted Response to always completely download before proceeding. This is not the case. `matchAll()` always get the incumbent record if exists. The downloading bits are want-to-be-incumbent record for the next fetch event. > Is it the intention to require add()/addAll()/put() to wait tor resolve until the new Response is complete even if there is an existing incumbent response? Yes. Incumbent record has higher priority. And the fulfillment of the cache-adding methods (add/addAll/put) guarantees we have the incumbent record fully ready for the request. Holding the promise resolution until it completes also solves the issue posed in https://github.com/slightlyoff/ServiceWorker/issues/665's OP. > Sorry for my confusion. Not at all. Sorry for having got back to the issue late. --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/361#issuecomment-113545874
Received on Friday, 19 June 2015 15:16:47 UTC