[Preinstalled-or-Packaged] Appcache issues

Potch 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 
https://etherpad.mozilla.org/appcache-gripes.

1) Security

 From the W3C spec 
(http://www.w3.org/TR/2011/WD-html5-20110525/offline.html)

     If the manifest's <scheme> is https: or another scheme intended for 
encrypted
     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.

2) FALLBACK:

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.

3) Rigidity

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 
mobile ecosystem.

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.

9) Usability

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.

10) Tooling

There are presently no tools out there that make generating, updating, 
ananlyzing, or debugging appcache easier for developers.


Best,
~potch


More information about the Packagedapps mailing list