Re: [ServiceWorker] Can Cache.add() committing at response resolution lead to duplicate requests? (#361)

> 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