AppCache

~ the last words ~

A cache manifest was a text file that started with the words CACHE MANIFEST and listed the files a browser should hold on to. You pointed at it from the html tag with a manifest attribute. The browser fetched everything on the list and kept it, so the page loaded with the network cable pulled out. For about five years that was the only way to get that, and it shipped in every browser that mattered.

The trouble started on the second visit. Once a page had an application cache the browser served it from there first, always, even on a fast connection with the server sitting right there. It checked the manifest for changes afterward, in the background, and if anything had moved it downloaded the new files and stored them for the next load. Not this load. The next one. Every update your users received was one visit behind unless you listened for the updateready event and forced a reload yourself.

The failure modes underneath were worse than the delay. A manifest was all or nothing, so a single 404 anywhere on the list aborted the whole update quietly and left the old cache sitting there. And any page that referenced a manifest got cached itself as a side effect, which meant dynamic HTML froze at whatever it happened to say the first time somebody loaded it.

By 2012 my work pointed at cameras and embedded boards, and the browser was somebody else's machine. I read the AppCache complaints the way you read a maintenance log for equipment you do not operate. The part that carried over was the shape of it: a cache that will not tell you what it is holding is the same bug in any language.

~ the record ~

~ the manifest ~

The syntax fit on a postcard. First line CACHE MANIFEST, then the list of URLs to keep. A NETWORK section marked the things that must always go to the server, and a FALLBACK section mapped URL prefixes to substitute pages for requests that failed. The file had to be served as text/cache-manifest or the browser ignored the whole thing.

Updates keyed off the bytes of the manifest rather than the files it named, so changing an image did nothing at all until the manifest changed too. The workaround everybody arrived at was a comment line holding a version number or a build hash, bumped on every deploy. Every build pipeline that shipped an offline site ended up writing that line.

~ the essay ~

On 8 May 2012 A List Apart published Jake Archibald's "Application Cache is a Douchebag", and the title did more work than the article, which is saying something, because the article was a complete field guide to the traps. It laid out the stale-first behavior and the silent update failures in enough detail that nobody went back to defending the API.

The W3C did try. A community group called Fixing Application Cache formed and met through 2012 with browser people in the room. What came out of it was not a repaired AppCache but a different design, one where you write JavaScript that intercepts every request and decides what to serve. That became service workers.

~ what replaced it ~

Firefox started printing a console warning in version 44 and removed the implementation in Firefox 84 on 15 December 2020. Safari deprecated it in early 2018. Chrome took the longest route out: gone from insecure contexts in Chrome 70 in October 2018, then off by default in Chrome 85 in August 2020, with a reverse origin trial for sites that needed longer to migrate.

That trial ran out on 5 October 2021 and the code came out with Chrome 95. Service workers had been shipping since 2015 and do the same job without offering any of the same promises. Nothing is cached unless your code caches it, and nothing comes back out of the cache unless your code hands it over.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »