17820 2012-07-18 06:55:00 +0000 appcache: avoid out-of-sync situations or cache busting when using appcache with non-sticky load balancers 2015-08-13 08:03:57 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX blocked awaiting response to comment 11 (please remove this when replying) P3 normal Unsorted 1 contributor ian annevk ian mike slightlyoff tobie.langel contributor oldest_to_newest 70110 0 contributor 2012-07-18 06:55:00 +0000 This was was cloned from bug 15771 as part of operation convergence. Originally filed: 2012-01-29 11:30:00 +0000 Original reporter: Tobie Langel <tobie.langel@gmail.com> ================================================================================ #0 Tobie Langel 2012-01-29 11:30:14 +0000 -------------------------------------------------------------------------------- Use case / explanation: An application is hosted on a cluster of servers behind a non-sticky load balancer. It is updated daily. Even though all servers are not updated instantly and two versions of the application co-exist for a while, it is possible to update the application without risking to have an out-of sync version of the application (e.g. manifest file and assets of the latest version combined with a Master Entry of the previous version) or to need to invalidate the cache to avoid such issues. ================================================================================ 74561 1 ian 2012-09-26 18:21:13 +0000 How is this problem solved when you're not using appcache? 76038 2 ian 2012-10-11 21:24:39 +0000 Tobie: Please see the question in comment 1 and reopen the bug. Thanks! 78437 3 tobie.langel 2012-11-17 10:40:47 +0000 This is generally done by adding a timestamp or checksum to resource URLs and serving them from a CDN (which can host resources from multiple versions of the application). This technique doesn't work when using AppCache because neither the master entry nor the manifest can have their URL fingerprinted. So which master entry and/or manifest end-up being picked up during update is non-deterministic. 82609 4 ian 2013-02-06 00:33:01 +0000 I don't understand how it's solved with fingerprinted URLs. Say you have two CDNs, A and B. Initially, A and B both fold the same files: A B index.html (v1) index.html (v2) script.js?v1 script.js?v1 style.css?v1 style.css?v1 Obviously, index.html here refers to both script.js?v1 and style.css?v1. Now, a new version of index.html, script.js, and sytle.css are pushed out. A gets the files first, so now A has an index.html that refers to v2 files, and it also has the v2 files, but B still has the old index.html: A B index.html (v2) index.html (v1) script.js?v1 script.js?v1 style.css?v1 style.css?v1 script.js?v2 style.css?v2 What happens if you hit A for index.html, and B for "script.js?v2"? Or am I misunderstanding the issue here? 109449 5 ian 2014-07-29 00:04:10 +0000 Tobie, can you elaborate? See comment 4. Thanks. 109470 6 tobie.langel 2014-07-29 08:48:21 +0000 Yeah, sorry. All the assets are hosted on a CDN. So the CDN hosts: script.v1.js style.v1.css script.v2.js style.v2.css And so the issue of hitting a server for a missing resource never arrises (as long as you prime the CDN before you start updating your servers). 109502 7 ian 2014-07-29 16:50:32 +0000 Tobie: So the problem is that you can't push both the index.html file and the manifest file to the CDN at the same time atomically? 109508 8 tobie.langel 2014-07-29 17:18:33 +0000 Right, that was the issue at Facebook. App was updated daily, then, and propagation across the clusters took > 1 hour. 111194 9 ian 2014-09-08 21:12:09 +0000 So basically, the problem is that traditionally, there's one file that has the list of resources (index.html), while with appcache, there must be two files: the index and the manifest. If you can't update them atomically, then they might reference different subresources. One lame solution would be have an intermediate manifest that listed all the files from both versions. So they you'd deploy as follows: - deploy new resources (script.v2.js, etc) - wait for that to be done - deploy new manifest that contains both v1 and v2 resources - wait for that to be done - deploy new index.html - wait for that to be done - deploy new manifest that contains only v2 resources - wait for that to be done - undeploy v1 resources 111196 10 tobie.langel 2014-09-08 21:35:56 +0000 I can't really imagine that happening, frankly. 111283 11 ian 2014-09-09 16:15:13 +0000 Well like I said, it's a lame solution. I'm not really sure what a better solution would be, though. Do you have any suggestions? Alex, does ServiceWorkers have a solution for this? 122576 12 annevk 2015-08-13 07:08:26 +0000 Sorry, appcache will no longer be maintained. 122578 13 tobie.langel 2015-08-13 08:03:57 +0000 What terrible news. :grin: