What's wrong with appcache?
(Originally published in 2011.)
The HTML5 application cache is one of the niftiest features to come along in quite a while, and I’m pretty enamoured of it. In the process of making use of it on a significant site, however, I’ve come across a number of shortcomings and annoyances. I created Appcache Facts to help spread the word, but there are some things that I’d love to see changed in a future revision of the draft. I’m not alone, either: a few days ago, Louis Remi wrote an article called Improving the AppCache that lists a few of his problems. In no particular order, here are my own pain points:
There is no way, from JavaScript, to clear the application cache. It’s possible, using a combination of JavaScript, cookies, and a back-end script, to cause the cache to be cleared, but only by having the browser try to update the manifest and returning a 404 instead.
-
The data passed along to the applicationCache’s “error” event handler contains no information about which resource it was downloading when the error occured. When debugging, you can infer it by counting the number of times the “progress” event is fired and looking for the corresponding line in your manifest file.
-
If the current page is being delivered over SSL, all resources in the manifest must be served from the same domain as the page. This means that it’s not possible to serve assets from a CDN — even if that CDN is secure. This makes the appcache completely unusable for large sites.
-
There’s no way to prevent the HTML of the current page from being cached. This isn’t surprising, since the original intent of the appcache was to enable offline use. However, the (appcache can also be leveraged to significantly improve load time of online applications. With that in mind, it would be nice to be able to opt-out of caching the current page.
In my opinion, it’s the third issue that poses the biggest barrier to adoption. CDNs are a critical part of infrastructure for many of the web’s largest sites. Happily enough, Chrome 11 willfully violates this part of the specification, and will allow cross-domain HTTPS resources so long as they are not served with a Cache-control: no-store header. I think this is exactly the correct behaviour. However, it would be preferable for the specification to evolve, rather than to have major browsers violate it intentionally.