This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17820 - appcache: avoid out-of-sync situations or cache busting when using appcache with non-sticky load balancers
Summary: appcache: avoid out-of-sync situations or cache busting when using appcache w...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard: blocked awaiting response to comment ...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 06:55 UTC by contributor
Modified: 2015-08-13 08:03 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2012-07-18 06:55:00 UTC 
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.
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-09-26 18:21:13 UTC 
How is this problem solved when you're not using appcache?
Comment 2 Ian 'Hixie' Hickson 2012-10-11 21:24:39 UTC 
Tobie: Please see the question in comment 1 and reopen the bug. Thanks!
Comment 3 Tobie Langel 2012-11-17 10:40:47 UTC 
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.
Comment 4 Ian 'Hixie' Hickson 2013-02-06 00:33:01 UTC 
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?
Comment 5 Ian 'Hixie' Hickson 2014-07-29 00:04:10 UTC 
Tobie, can you elaborate? See comment 4. Thanks.
Comment 6 Tobie Langel 2014-07-29 08:48:21 UTC 
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).
Comment 7 Ian 'Hixie' Hickson 2014-07-29 16:50:32 UTC 
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?
Comment 8 Tobie Langel 2014-07-29 17:18:33 UTC 
Right, that was the issue at Facebook. App was updated daily, then, and propagation across the clusters took > 1 hour.
Comment 9 Ian 'Hixie' Hickson 2014-09-08 21:12:09 UTC 
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
Comment 10 Tobie Langel 2014-09-08 21:35:56 UTC 
I can't really imagine that happening, frankly.
Comment 11 Ian 'Hixie' Hickson 2014-09-09 16:15:13 UTC 
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?
Comment 12 Anne 2015-08-13 07:08:26 UTC 
Sorry, appcache will no longer be maintained.
Comment 13 Tobie Langel 2015-08-13 08:03:57 UTC 
What terrible news. :grin: