The WebPlatform project has been discontinued when the Stewards partnership agreement ended in September 2015. This site has been frozen, and the assets we have created will remain.
This article is Ready to Use.
W3C Editor's Draft
The Application Cache (AppCache) lets web-based applications run offline. Developers can specify resources for the browser to cache, making them available to the application even if no connection can be made to the server. These resources load and work correctly even if users click the refresh button when they are offline.
An application cache provides the following benefits:
- Offline browsing: users can navigate a site or use a web application although they are offline
- Speed: cached resources are local, and therefore load faster
- Reduced server load: the browser only downloads resources that have changed from the server.
|oncached||The resources listed in the manifest have been downloaded, and the application is now cached.|
|onerror||Indicates an error has occurred.|
|onobsolete||The Webpage is associated with an application cache whose group is marked as obsolete.|
|onprogress||The user agent is downloading resources listed by the manifest. The event object's total attribute returns the total number of files to be downloaded. The event object's loaded attribute returns the number of files processed so far.|
|onupdateready||The ApplicationCache object's cache host is associated with an application cache whose application cache group's update status is idle, and whose application cache group is not marked as obsolete, but that application cache is not the newest cache in its group.|
|status||Returns the current status of the application cache, as given by the constants defined below.|
|swapCache|| Switches to the most recent application cache, if there is a newer one. If there isn't, throws an InvalidStateError exception.
This does not cause previously-loaded resources to be reloaded; for example, images do not suddenly get reloaded and style sheets and scripts do not get reparsed or reevaluated. The only change is that subsequent requests for cached resources will obtain the newer copies.
The updateready event will fire before this method can be called. Once it fires, the Web application can, at its leisure, call this method to switch the underlying cache to the one with the more recent updates. To make proper use of this, applications have to be able to bring the new features into play; for example, reloading scripts to enable new features. An easier alternative to
In order to cache files, you must do the following:
- Create a manifest file that lists the files and other web resources you want to cache.
- Reference the manifest file in the header of every page you want cached.
The manifest file
The manifest file defines which web resources are cached when a user browses to your site. The manifest file typically has the extension .appcache or .manifest. Each webpage must add a manifest attribute to the HTML element similar to this:
You can use an absolute or relative URL. The cache manifest file lists the files that will be cached, using the format:
CACHE MANIFEST # Version 1 CACHE: script/scriptfilename1.js css/cssfilename.css images/imagename1.png images/imagename2.jpg images/imagename3.png FALLBACK: # This will enable imagename4.png to be as a replacement for # all resources under the images dir when there is no network connectivity. images/ images/imagename4.png NETWORK: # This will prevent other network resources from being accessed. images/imagename5.png
The first line of the manifest must read CACHE MANIFEST and the lines that follow it list the web resources you want to cache. You can use the # symbol to make comments.
Alternatively, web resources that need to be cached can be specified by adding a “CACHE:” header section before the resources (as shown previously). In addition, fallback resources can be defined to replace general or specific web resources when there is no network connectivity. This is done by adding a “FALLBACK:” header section before the resources. These resources can be wildcard to specify a catch all mechanism (as shown previously). Be aware that there is a space after the first "images/" in the FALLBACK: section. This indicates that any files contained under the "images/" directory will fall back to a specific web resource (for example, images/imagename4.png) if they cannot be accessed from the network. Also, web resources can be specified to only be loaded from the network. This is done by adding a "NETWORK: " header section before the resources. This functionality can be used to scope down the number of resources that can be accessed from the network, thus, creating an allowed only list (as shown previously).
|CACHE||This is the default section for entries. Files listed under this header (or immediately after the CACHE MANIFEST) will be explicitly cached after they're downloaded for the first time.|
|NETWORK||Files listed under this section are white-listed resources that require a connection to the server. All requests to these resources bypass the cache, even if the user is offline. Wildcards may be used.|
|FALLBACK||An optional section specifying fallback pages if a resource is inaccessible. The first URI is the resource, the second is the fallback. Both URIs must be relative and from the same origin as the manifest file. Wildcards may be used.|
ApplicationCache functionality is independent of HTTP caching headers. The manifest file implicitly includes itself as a page to be cached. It also needs to have the same domain of origin as the page that contains it.
|W3C ApplicationCache Specification||W3C Editor's Draft|