[Preinstalled-or-Packaged] Appcache issues
potch at mozilla.com
Wed Jan 2 13:55:57 PST 2013
10 Things I Hate About AppCache
After a frustrating and presently on-hold experience implementing the
HTML5 Offline Cache for marketplace.firefox.com, I was asked to submit a
list of issues encountered, to be turned into bugs.
The gripes that follow are a mix of actual bugs (things that deviate
from specified behavior), complaints about existing specified behavior,
and more general issues with implementing a cache from the viewpoint of
a web developer. Each of these issues is in my opinion a worthy
candidate for a bug, and I will begin filing them shortly. This list is
not exhaustive, nor is it in any particular order.
The living version of this list lives at
From the W3C spec
If the manifest's <scheme> is https: or another scheme intended for
data transfer, then all URLs in explicit sections must have the
same origin as
the manifest itself.
The practical effect of this rule is that media served from a CDN cannot
be included in the cache manifest without triggering a Mixed Content
warning. This conflicts with common development and scalability best
practices. Chrome notably ignores this part of the spec, and no issues
are reported for using secure CDNs that do not match the primary origin.
The fallback section treats the first part of each directive as a
prefix. This *seems* like a great idea. However, what if one wants to
produce a fallback for the homepage? Putting '/' in the FALLBACK section
caches the entire site, which is likely never what we want. Seems like a
dangerous default. Though the point here isn't to be prescriptive, I
will note the '*' character already has special meaning in appcache
manifests, and to use it to denote a prefix would have been swell.
Another heavily used web development best practice is using query
parameters to cache-bust external resources. For example, <script
src="lib.js?v1"> to ensure the client isn't serving the wrong media. In
a mature or highly automated toolchain (like the one in use by the
Mozilla WebDev team), these queryparams are generated by the server
automatically. However, appcache will not return a cached file unless
the URI matches exactly. This means that the process of generating our
appcache manifests must be aware and capable of knowing what precise
URIs are being served by a dynamic website.
4) Black Box
There is presently no (sane) way to introspect the current status or
contents of a site's applicationCache object in Firefox. This is not
acceptable for a tool we are promoting as an offline solution for our
update: I just learned about about:cache?device=offline, so this point
partially retracted, though that UI is less than discoverable or intuitive.
5) Binary Error Reporting
Related to the black box complaint above, The only information available
about an error encountered in the process of updating the cache is that
one occurred at all. There is no way to determine which particular line
of the manifest failed, or what URI did not fetch properly.
6) Why is it even possible to accidentally cache the manifest itself??
7) Rigidity pt. 2
The all-or-nothing nature of the cache is in stark contrast with the
fault-tolerant nature of the Web. If a resource fails to load, throwing
everything away is wasteful of bandwidth and abusive to users and
developers, especially given the poor error reporting and the
data-usage-conscious markets in which we intend to launch. Additionally, 301
8) Cache-Control headers should have no say
Even if explicitly included in the manifest, any resource with a
"Cache-Control: no-store" header is not cached by Firefox. This is in
violation of the spec, which states:
HTTP caching rules, such as Cache-Control: no-store, are ignored
for the purposes of the application cache download process.
Note that Chrome does respect this.
Figuring out appcache is hard. The appcache manifest is entirely unique
in terms of syntax and behavior from anything else out there. Versioning
an offline manifest is merely a side-effect of commenting. While that
may be elegant, it is confusing.
There are presently no tools out there that make generating, updating,
ananlyzing, or debugging appcache easier for developers.
More information about the Packagedapps