#Proposed extensions to application cache

The application cache is close to being a wonderful technology, but falls short of usability in a few key areas. I propose a few extensions to the standard in two broad categories: extensions to the application cache itself, and extensions to the JavaScript interface that browsers expose.

##Extensions to the application cache itself

###Manifest exclusions. These would allow the page to exclude resources that would ordinarily be included due to a wildcard.

Precedence is up for debate. There are basically three choices:

  1. Exclusions are always higher precedence than inclusions
  2. Respect order of declaration
  3. Respect specificity, similar to how CSS determines precedence

I personally favour #1, because simple rules are easier to work with and remember.

Proposed syntax: prefix lines with a minus followed by a space (- ).

For example:

- /resources/uncached/*

###Making HTML caching optional This is intended to facilitate the use case of speeding up online applications, allowing non-blocking updates of important but non-critical resources.

Proposed syntax: leverage manifest exclusions to simply exclude the path to the current page. For example, if www.example.com/index.html was appcached, the manifest might include this:

- /index.html

###Automatically expire and refresh cached data There are some use cases where it would be nice to refresh the appcached data prior to rendering the page (if the browser was currently online, of course). One obvious example is if a security vulnerability is fixed in the latest version of a page.

Proposed syntax: a MIN_TIMESTAMP value in the manifest would indicate that we want to check the manifest prior to rendering the page when possible. If the previously cached data is older than the current minimum timestamp, discard it and act as if we have no cached data.

MIN_TIMESTAMP 1320451230

Note: This can currently be accomplished via an out-of-band signaling and JavaScript that runs in the page that’s being cached, but first-class support would be nice.

###Quota information There are some use cases where the contents of the manifest may vary based on how much disk space is available — for example, using a set of higher resolution images if the client has the capacity for them.

I suggest adding at least two of the following headers to HTTP requests for the manifest file:


These would indicate the number of bytes available/total/used.

##Extensions to the JavaScript interface

###Cache flushing There is currently no way to clear the current page’s appcached data (although it’s possible to trigger an expiry with the aid of a server and a clever endpoint).

Calling this method should remove all appcached data for the current page:


When this is complete, it should fire an event (cleared) and set applicationCache.status to applicationCache.CLEARED.

###Quota information There is currently no way to determine how much space is available for appcached data. I suggest adding at least two of the following values:

// total number of bytes available for this page's application cache

// number of bytes currently used for this page's application cache

// remaining number of bytes available for this page's application cache