Re: [ServiceWorker] 24 hour spontaneous update doesn't seem specced (#514)

Re-open to discuss the criteria for bypassing the browser cache. 

The registration's _last update time_ is used for this purpose in the spec and the value is updated only when a new version is fetched from the network and the resource is new. (I.e., it doesn't care whether the subsequent installation fails. And it's not updated when the response's status was 304 - i.e. the resource in the server is still byte-for-byte match.)

On the other hand, the current chrome implementation show a bit different behavior. It has a corresponding member, |last_update_check|, on the registration, and the value is updated in two cases: 1) when the response's status was 304 or 2) the new version of the resource has been received and successfully installed. (That is, it doesn't update the value when the installation fails even if it actually fetched a new script resource from the network.)

I've been pondering upon this browser cache bypassing rule for a bit. I think the overall rule is "we must go to the network if we haven't within 24 hours". (max-age is covered by the network layer anyway.)

That considered, I'd want to suggest we just use the simplest rule where the registration's _last update check time_ is updated if and only if the response is gotten from the network. (i.e. including 304 case; and we don't care about the subsequent installation for this new resource.) I think we can check the condition using response's cache state is not "local".

I think we should not take the installation failure into account here as, coming back to the overall rule, we already hit the network and the browser cache should have already been bumped with this new resource.

Thoughts?

/cc @jakearchibald @nhiroki 

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/514#issuecomment-134862905