4

When taking a page offline, the browser will (glossing over the details) download the page, its manifest, and its resources, and then when done it will re-request the manifest (Step 24 here), and if what it gets back doesn't match the first one it got, caching fails.

According to the spec, the browser should then schedule another attempt after a "short delay" (Step 25). Sadly, as far as I can tell, neither Chrome nor Firefox does that last part; instead, they just fail to cache (or update) the page and don't retry it.

So in order for pages to be reliably cached/updated, we need to make sure the second copy of the manifest is a byte-for-byte copy of the first one from just a few moments before.

If the data for the page already has some kind of built-in version you can use in the manifest, great, but if not it seems your options are:

  1. Generate some kind of synthetic version and remember it on the server so that you can return the same version for the two requests.

  2. Allow the browser to cache the manifest for a short time (say, up to two minutes) in its normal cache; that way, the second request for it is satisfied by the browser's normal cache, and thus is always byte-for-byte. Of course, that means you can't update the page within those two minutes.

I'm not seeing anything in the spec, but is there any way to avoid that second manifest load entirely, so as to avoid either option? To tell the browser that the point-in-time of the first manifest is fine, we don't want it to recheck after? (In our case, we know for sure the world won't change half-way through downloading the resources, so the reason for the second check doesn't apply to us.)

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • AFAIK, there is no way to *tell the browser that the point-in-time of the first manifest is fine*. BTW, since **ServiceWorker - Cache API** is considered as the replacement for appcache in near future, I recommend you to spend your time with it instead of appcache. – Lewis Apr 23 '15 at 04:04
  • @Tresdin: Thanks. Yes, looking forward to service workers, but our app is live **now**, and service workers just aren't an option in the wild yet. But yes, looking forward, because I couldn't agree with the title of Jake Archibald's article [*Application Cache is a Douchebag*](http://alistapart.com/article/application-cache-is-a-douchebag) more... :-) – T.J. Crowder Apr 23 '15 at 07:40
  • Out of curiosity. Since the second check is trivial, why do you need to save it? – Lewis Apr 23 '15 at 08:43
  • I covered that in the question -- it's the pain of making the second copy match the first, but being able to update. – T.J. Crowder Apr 23 '15 at 08:47
  • Do you mean that the entire cached files will be re-downloaded? Just because it's never gonna happen with a correct implementation. – Lewis Apr 23 '15 at 08:55
  • @Tresdin: No, **the manifest**. I go on about it a fair bit above. – T.J. Crowder Apr 23 '15 at 08:58
  • Possible duplicate of [prevent ajax call if application cache is being updated](http://stackoverflow.com/questions/26241217/prevent-ajax-call-if-application-cache-is-being-updated) – Paul Sweatte Sep 28 '16 at 08:28
  • @PaulSweatte: Other than being generally about application cache, I don't see any relationship between that question and this one. Neither the question nor the answer relate to the browser's second request of the manifest. Perhaps you can clarify why you think it relates? – T.J. Crowder Sep 28 '16 at 08:45

0 Answers0