1

If the manifest contains files that are either too large or cumulatively too large, or there's a networking issue, caching will fail. Is there a fall back method the code can reliably use to still work?

For example, could the page have JavaScript that loads the files and puts them into the local database (indexedDB or websql)? or will the page itself still not cache? It seems as though any failure is catastrophic.

Don Rhummy
  • 24,730
  • 42
  • 175
  • 330
  • This is one of the many reasons [Service Workers](http://www.w3.org/TR/service-workers/) can't arrive soon enough. :-| – T.J. Crowder Aug 25 '15 at 15:11

1 Answers1

1

There is no fallback. Your page will work as normal, but no part of it will not be inserted into the Appcache if any component fails to be cached, regardless of the reason for the failure. You cannot reimplement the Appcache in JavaScript as a fallback.

If you're really concerned about this, you should store the minimal set of files required to bootstrap your application, and store all other data in the IndexedDB, so that your minimal app is guaranteed to fit inside the Appcache.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • thank you. the problem is some browser's don't implement indexeddb. is there a JavaScript library that can detect that and store them in the appropriate db? also, is there a total limit of appcache + db size? – Don Rhummy Aug 25 '15 at 16:55
  • @DonRhummy There really isn't another suitable storage mechanism, and if the browser doesn't support indexedDB, I wouldn't expect it to support the appcache. – user229044 Aug 25 '15 at 19:20
  • ios safari 7.1 supports appcache but not indexeddb – Don Rhummy Aug 25 '15 at 20:30
  • browsers that don't support indexeddb often supprt websql, and if not, support at least localStorage. At least the ones that support AppCache. Note also that it is also now better to use serviceWorkers than AppCache when supported. – Alexandre Morgaut Jun 05 '16 at 19:41