This is revision 1.5612.
This section is non-normative.
In order to enable users to continue interacting with Web applications and documents even when their network connection is unavailable — for instance, because they are traveling outside of their ISP's coverage area — authors can provide a manifest which lists the files that are needed for the Web application to work offline and which causes the user's browser to keep a copy of the files for use offline.
To illustrate this, consider a simple clock applet consisting of
an HTML page "clock.html
", a CSS style sheet
"clock.css
", and a JavaScript script "clock.js
".
Before adding the manifest, these three files might look like this:
<!-- clock.html --> <!DOCTYPE HTML> <html> <head> <title>Clock</title> <script src="clock.js"></script> <link rel="stylesheet" href="clock.css"> </head> <body> <p>The time is: <output id="clock"></output></p> </body> </html>
/* clock.css */ output { font: 2em sans-serif; }
/* clock.js */ setTimeout(function () { document.getElementById('clock').value = new Date(); }, 1000);
If the user tries to open the "clock.html
"
page while offline, though, the user agent (unless it happens to
have it still in the local cache) will fail with an error.
The author can instead provide a manifest of the three files, say
"clock.appcache
":
CACHE MANIFEST clock.html clock.css clock.js
With a small change to the HTML file, the manifest (served as
text/cache-manifest
) is linked to the application:
<!-- clock.html --> <!DOCTYPE HTML> <html manifest="clock.appcache"> <head> <title>Clock</title> <script src="clock.js"></script> <link rel="stylesheet" href="clock.css"> </head> <body> <p>The time is: <output id="clock"></output></p> </body> </html>
Now, if the user goes to the page, the browser will cache the files and make them available even when the user is offline.
Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly mentioned.
With the exception of "no-store" directive, HTTP
cache headers and restrictions on caching pages served over TLS
(encrypted, using https:
) are overridden by
manifests. Thus, pages will not expire from an application cache
before the user agent has updated it, and even applications served
over TLS can be made to work offline.
This section is non-normative.
When the user visits a page that declares a manifest, the browser will try to update the cache. It does this by fetching a copy of the manifest and, if the manifest has changed since the user agent last saw it, redownloading all the resources it mentions and caching them anew.
As this is going on, a number of events get fired on the
ApplicationCache
object to keep the script updated as
to the state of the cache update, so that the user can be notified
appropriately. The events are as follows:
Event name | Interface | Fired when... | Next events |
---|---|---|---|
checking
| Event
| The user agent is checking for an update, or attempting to download the manifest for the first time. This is always the first event in the sequence. | noupdate , downloading , obsolete , error
|
noupdate
| Event
| The manifest hadn't changed. | Last event in sequence. |
downloading
| Event
| The user agent has found an update and is fetching it, or is downloading the resources listed by the manifest for the first time. | progress , error , cached , updateready
|
progress
| ProgressEvent
| The user agent is downloading resources listed by the manifest. | progress , error , cached , updateready
|
cached
| Event
| The resources listed in the manifest have been downloaded, and the application is now cached. | Last event in sequence. |
updateready
| Event
| The resources listed in the manifest have been newly redownloaded, and the script can use swapCache() to switch to the new cache.
| Last event in sequence. |
obsolete
| Event
| The manifest was found to have become a 404 or 410 page, so the application cache is being deleted. | Last event in sequence. |
error
| Event
| The manifest was a 404 or 410 page, so the attempt to cache the application has been aborted. | Last event in sequence. |
The manifest hadn't changed, but the page referencing the manifest failed to download properly. | |||
A fatal error occurred while fetching the resources listed in the manifest. | |||
The manifest changed while the update was being run. | The user agent will try fetching the files again momentarily. |
An application cache is a set of cached resources consisting of:
One or more resources (including their out-of-band metadata, such as HTTP headers, if any), identified by URLs, each falling into one (or more) of the following categories:
These are documents that were added to the
cache because a browsing context was navigated to that document and the
document indicated that this was its cache, using the manifest
attribute.
This is the resource corresponding to the URL
that was given in a master entry's html
element's
manifest
attribute. The
manifest is fetched and processed during the application
cache download process. All the master entries have the
same origin as the manifest.
These are the resources that were listed in the cache's manifest in an explicit section.
These are the resources that were listed in the cache's manifest in a fallback section.
Explicit entries
and Fallback
entries can be marked as foreign, which means that
they have a manifest
attribute but that it doesn't point at this cache's manifest.
A URL in the list can be flagged with multiple different types, and thus an entry can end up being categorized as multiple entries. For example, an entry can be a manifest entry and an explicit entry at the same time, if the manifest is listed within the manifest.
Zero or more fallback namespaces, each of which is mapped to a fallback entry.
These are URLs used as prefix match patterns for resources that are to be fetched from the network if possible, or to be replaced by the corresponding fallback entry if not. Each namespace URL has the same origin as the manifest.
Zero or more URLs that form the online whitelist namespaces.
These are used as prefix match patterns, and declare URLs for which the user agent will ignore the application cache, instead fetching them normally (i.e. from the network or locale HTTP cache as appropriate).
An online whitelist wildcard flag, which is either open or blocking.
The open state indicates that any URL not listed as cached is to be implicitly treated as being in the online whitelist namespaces; the blocking state indicates that URLs not listed explicitly in the manifest are to be treated as unavailable.
Each application cache has a completeness flag, which is either complete or incomplete.
An application cache group is a group of application caches, identified by the absolute URL of a resource manifest which is used to populate the caches in the group.
An application cache is newer than another if it was created after the other (in other words, application caches in an application cache group have a chronological order).
Only the newest application cache in an application cache group can have its completeness flag set to incomplete; the others are always all complete.
Each application cache group has an update status, which is one of the following: idle, checking, downloading.
A relevant application cache is an application cache that is the newest in its group to be complete.
Each application cache group has a list of pending master
entries. Each entry in this list consists of a resource and a
corresponding Document
object. It is used during the
application cache download process to ensure that new
master entries are cached even if the application cache
download process was already running for their
application cache group when they were loaded.
An application cache group can be marked as obsolete, meaning that it must be ignored when looking at what application cache groups exist.
A cache host is a Document
or a
SharedWorkerGlobalScope
object. A cache
host can be associated with an application
cache.
[WEBWORKERS]
A Document
initially is not associated with an
application cache, but can become associated with one
early during the page load process, when steps in the parser and in the navigation sections cause cache selection to occur.
A SharedWorkerGlobalScope
can be associated with an
application cache when it is created.
[WEBWORKERS]
Each cache host has an associated
ApplicationCache
object.
Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following:
A URL matches a fallback namespace if there exists a relevant application cache whose manifest's URL has the same origin as the URL in question, and that has a fallback namespace that is a prefix match for the URL being examined. If multiple fallback namespaces match the same URL, the longest one is the one that matches. A URL looking for a fallback namespace can match more than one application cache at a time, but only matches one namespace in each cache.
If a manifest http://example.com/app1/manifest
declares that
http://example.com/resources/images
is a
fallback namespace, and the user navigates to HTTP://EXAMPLE.COM:80/resources/images/cat.png
,
then the user agent will decide that the application cache
identified by http://example.com/app1/manifest
contains a
namespace with a match for that URL.
This section is non-normative.
This example manifest requires two images and a style sheet to be cached and whitelists a CGI script.
CACHE MANIFEST # the above line is required # this is a comment # there can be as many of these anywhere in the file # they are all ignored # comments can have spaces before them # but must be alone on the line # blank lines are ignored too # these are files that need to be cached they can either be listed # first, or a "CACHE:" header could be put before them, as is done # lower down. images/sound-icon.png images/background.png # note that each file has to be put on its own line # here is a file for the online whitelist -- it isn't cached, and # references to this file will bypass the cache, always hitting the # network (or trying to, if the user is offline). NETWORK: comm.cgi # here is another set of files to cache, this time just the CSS file. CACHE: style/default.css
It could equally well be written as follows:
CACHE MANIFEST NETWORK: comm.cgi CACHE: style/default.css images/sound-icon.png images/background.png
Offline application cache manifests can use absolute paths or even absolute URLs:
CACHE MANIFEST /main/home /main/app.js /settings/home /settings/app.js http://img.example.com/logo.png http://img.example.com/check.png http://img.example.com/cross.png
The following manifest defines a catch-all error page that is displayed for any page on the site while the user is offline. It also specifies that the online whitelist wildcard flag is open, meaning that accesses to resources on other sites will not be blocked. (Resources on the same site are already not blocked because of the catch-all fallback namespace.)
So long as all pages on the site reference this manifest, they will get cached locally as they are fetched, so that subsequent hits to the same page will load the page immediately from the cache. Until the manifest is changed, those pages will not be fetched from the server again. When the manifest changes, then all the files will be redownloaded.
Subresources, such as style sheets, images, etc, would only be cached using the regular HTTP caching semantics, however.
CACHE MANIFEST FALLBACK: / /offline.html NETWORK: *
Manifests must be served using the
text/cache-manifest
MIME type. All
resources served using the text/cache-manifest
MIME type must follow the syntax of application cache
manifests, as described in this section.
An application cache manifest is a text file, whose text is encoded using UTF-8. Data in application cache manifests is line-based. Newlines must be represented by "LF" (U+000A) characters, "CR" (U+000D) characters, or "CR" (U+000D) "LF" (U+000A) pairs. [RFC3629]
This is a willful violation of RFC
2046, which requires all text/*
types to only
allow CRLF line breaks. This requirement, however, is outdated; the
use of CR, LF, and CRLF line breaks is commonly supported and indeed
sometimes CRLF is not supported by text editors. [RFC2046]
The first line of an application cache manifest must consist of the string "CACHE", a single U+0020 SPACE character, the string "MANIFEST", and either a U+0020 SPACE character, a "tab" (U+0009) character, a "LF" (U+000A) character, or a "CR" (U+000D) character. The first line may optionally be preceded by a "BOM" (U+FEFF) character. If any other text is found on the first line, it is ignored.
Subsequent lines, if any, must all be one of the following:
Blank lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters only.
Comment lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, followed by a single "#" (U+0023) character, followed by zero or more characters other than "LF" (U+000A) and "CR" (U+000D) characters.
Comments must be on a line on their own. If they were to be included on a line with a URL, the "#" would be mistaken for part of a fragment identifier.
Section headers change the current section. There are three possible section headers:
CACHE:
FALLBACK:
NETWORK:
Section header lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, followed by one of the names above (including the ":)" (U+003A) character followed by zero or more U+0020 SPACE and "tab" (U+0009) characters.
Ironically, by default, the current section is the explicit section.
The format that data lines must take depends on the current section.
When the current section is the explicit section, data lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, a valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and "tab" (U+0009) characters.
When the current section is the fallback section, data lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, a valid URL identifying a resource other than the manifest itself, one or more U+0020 SPACE and "tab" (U+0009) characters, another valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and "tab" (U+0009) characters.
When the current section is the online whitelist section, data lines must consist of zero or more U+0020 SPACE and "tab" (U+0009) characters, either a single "*" (U+002A) character or a valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and "tab" (U+0009) characters.
Manifests may contain sections more than once. Sections may be empty.
URLs that are to be fallback pages associated with fallback namespaces, and those namespaces themselves, must be given in fallback sections, with the namespace being the first URL of the data line, and the corresponding fallback page being the second URL. All the other pages to be cached must be listed in explicit sections.
Fallback namespaces and fallback entries must have the same origin as the manifest itself.
A fallback namespace must not be listed more than once.
Namespaces that the user agent is to put into the online whitelist must all be specified in online whitelist sections. (This is needed for any URL that the page is intending to use to communicate back to the server.) To specify that all URLs are automatically whitelisted in this way, a "*" (U+002A) character may be specified as one of the URLs.
Authors should not include namespaces in the online whitelist for which another namespace in the online whitelist is a prefix match.
Relative URLs must be given relative to the manifest's own URL. All URLs in the manifest must have the same <scheme> as the manifest itself (either explicitly or implicitly, through the use of relative URLs).
URLs in manifests must not have fragment identifiers (i.e. the U+0023 NUMBER SIGN character isn't allowed in URLs in manifests).
Fallback namespaces and namespaces in the online whitelist are matched by prefix match.
When a user agent is to parse a manifest, it means that the user agent must run the following steps:
The user agent must decode the byte stream corresponding with the manifest to be parsed as UTF-8, with error handling.
Let base URL be the absolute URL representing the manifest.
Let explicit URLs be an initially empty list of absolute URLs for explicit entries.
Let fallback URLs be an initially empty mapping of fallback namespaces to absolute URLs for fallback entries.
Let online whitelist namespaces be an initially empty list of absolute URLs for an online whitelist.
Let online whitelist wildcard flag be blocking.
Let input be the decoded text of the manifest's byte stream.
Let position be a pointer into input, initially pointing at the first character.
If position is pointing at a "BOM" (U+FEFF) character, then advance position to the next character.
If the characters starting from position are "CACHE", followed by a U+0020 SPACE character, followed by "MANIFEST", then advance position to the next character after those. Otherwise, this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.
If the character at position is neither a U+0020 SPACE character, a "tab" (U+0009) character, "LF" (U+000A) character, nor a "CR" (U+000D) character, then this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.
This is a cache manifest. The algorithm cannot fail beyond this point (though bogus lines can get ignored).
Collect a sequence of characters that are not "LF" (U+000A) or "CR" (U+000D) characters, and ignore those characters. (Extra text on the first line, after the signature, is ignored.)
Let mode be "explicit".
Start of line: If position is past the end of input, then jump to the last step. Otherwise, collect a sequence of characters that are "LF" (U+000A), "CR" (U+000D), U+0020 SPACE, or "tab" (U+0009) characters.
Now, collect a sequence of characters that are not "LF" (U+000A) or "CR" (U+000D) characters, and let the result be line.
Drop any trailing U+0020 SPACE and "tab" (U+0009) characters at the end of line.
If line is the empty string, then jump back to the step labeled "start of line".
If the first character in line is a "#" (U+0023) character, then jump back to the step labeled "start of line".
If line equals "CACHE:" (the word "CACHE" followed by a ":)" (U+003A) character, then set mode to "explicit" and jump back to the step labeled "start of line".
If line equals "FALLBACK:" (the word "FALLBACK" followed by a ":)" (U+003A) character, then set mode to "fallback" and jump back to the step labeled "start of line".
If line equals "NETWORK:" (the word "NETWORK" followed by a ":)" (U+003A) character, then set mode to "online whitelist" and jump back to the step labeled "start of line".
If line ends with a ":" (U+003A) character, then set mode to "unknown" and jump back to the step labeled "start of line".
This is either a data line or it is syntactically incorrect.
Let position be a pointer into line, initially pointing at the start of the string.
Let tokens be a list of strings, initially empty.
While position doesn't point past the end of line:
Let current token be an empty string.
While position doesn't point past the end of line and the character at position is neither a U+0020 SPACE nor a "tab" (U+0009) character, add the character at position to current token and advance position to the next character in input.
Add current token to the tokens list.
While position doesn't point past the end of line and the character at position is either a U+0020 SPACE or a "tab" (U+0009) character, advance position to the next character in input.
Process tokens as follows:
Resolve the first item in tokens, relative to base URL; ignore the rest.
If this fails, then jump back to the step labeled "start of line".
If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".
Drop the <fragment> component of the resulting absolute URL, if it has one.
Add the resulting absolute URL to the explicit URLs.
Let part one be the first token in tokens, and let part two be the second token in tokens.
Resolve part one and part two, relative to base URL.
If either fails, then jump back to the step labeled "start of line".
If the absolute URL corresponding to either part one or part two does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".
Drop any <fragment> components of the resulting absolute URLs.
If the absolute URL corresponding to part one is already in the fallback URLs mapping as a fallback namespace, then jump back to the step labeled "start of line".
Otherwise, add the absolute URL corresponding to part one to the fallback URLs mapping as a fallback namespace, mapped to the absolute URL corresponding to part two as the fallback entry.
If the first item in tokens is a "*" (U+002A) character, then set online whitelist wildcard flag to open and jump back to the step labeled "start of line".
Otherwise, resolve the first item in tokens, relative to base URL; ignore the rest.
If this fails, then jump back to the step labeled "start of line".
If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".
Drop the <fragment> component of the resulting absolute URL, if it has one.
Add the resulting absolute URL to the online whitelist namespaces.
Do nothing. The line is ignored.
Jump back to the step labeled "start of line". (That step jumps to the next, and last, step when the end of the file is reached.)
Return the explicit URLs list, the fallback URLs mapping, the online whitelist namespaces, and the online whitelist wildcard flag.
The resource that declares the manifest (with the manifest
attribute) will always
get taken from the cache, whether it is listed in the cache or not,
even if it is listed in an online whitelist
namespace.
If a resource is listed in the explicit section or as a fallback entry in the fallback section, the resource will always be taken from the cache, regardless of any other matching entries in the fallback namespaces or online whitelist namespaces.
When a fallback namespace and an online whitelist namespace overlap, the online whitelist namespace has priority.
The online whitelist wildcard flag is applied last, only for URLs that match neither the online whitelist namespace nor the fallback namespace and that are not listed in the explicit section.
When the user agent is required (by other parts of this specification) to start the application cache download process for an absolute URL purported to identify a manifest, or for an application cache group, potentially given a particular cache host, and potentially given a master resource, the user agent must run the steps below. These steps are always run asynchronously, in parallel with the event loop tasks.
Some of these steps have requirements that only apply if the user agent shows caching progress. Support for this is optional. Caching progress UI could consist of a progress bar or message panel in the user agent's interface, or an overlay, or something else. Certain events fired during the application cache download process allow the script to override the display of such an interface. The goal of this is to allow Web applications to provide more seamless update mechanisms, hiding from the user the mechanics of the application cache mechanism. User agents may display user interfaces independent of this, but are encouraged to not show prominent update progress notifications for applications that cancel the relevant events.
These events are delayed until after the load
event has fired.
The application cache download process steps are as follows:
Optionally, wait until the permission to start the application cache download process has been obtained from the user and until the user agent is confident that the network is available. This could include doing nothing until the user explicitly opts-in to caching the site, or could involve prompting the user for permission. The algorithm might never get past this point. (This step is particularly intended to be used by user agents running on severely space-constrained devices or in highly privacy-sensitive environments).
Atomically, so as to avoid race conditions, perform the following substeps:
Pick the appropriate substeps:
Let manifest URL be that absolute URL.
If there is no application cache group identified by manifest URL, then create a new application cache group identified by manifest URL. Initially, it has no application caches. One will be created later in this algorithm.
Let manifest URL be the absolute URL of the manifest used to identify the application cache group to be updated.
If that application cache group is obsolete, then abort this instance of the application cache download process. This can happen if another instance of this algorithm found the manifest to be 404 or 410 while this algorithm was waiting in the first step above.
Let cache group be the application cache group identified by manifest URL.
If these steps were invoked with a master resource, then add
the resource, along with the resource's Document
, to
cache group's list of pending master
entries.
If these steps were invoked with a cache
host, and the status of cache group is checking or
downloading, then queue a post-load task to
fire a simple event named checking
that is
cancelable at the ApplicationCache
singleton of that
cache host. The default action of this event must
be, if the user agent shows caching progress, the
display of some sort of user interface indicating to the user
that the user agent is checking to see if it can download the
application.
If these steps were invoked with a cache
host, and the status of cache group is downloading, then also
queue a post-load task to fire a simple
event named downloading
that is
cancelable at the ApplicationCache
singleton of that
cache host. The default action of this event must
be, if the user agent shows caching progress, the
display of some sort of user interface indicating to the user the
application is being downloaded.
If the status of the cache group is either checking or downloading, then abort this instance of the application cache download process, as an update is already in progress.
Set the status of cache group to checking.
For each cache host associated with an
application cache in cache
group, queue a post-load task to fire a
simple event that is cancelable named checking
at the
ApplicationCache
singleton of the cache
host. The default action of these events must be, if the
user agent shows caching progress, the display of
some sort of user interface indicating to the user that the user
agent is checking for the availability of updates.
The remainder of the steps run asynchronously.
If cache group already has an application cache in it, then this is an upgrade attempt. Otherwise, this is a cache attempt.
If this is a cache
attempt, then this algorithm was invoked with a cache
host; queue a post-load task to fire a
simple event named checking
that is cancelable
at the ApplicationCache
singleton of that cache
host. The default action of this event must be, if the user
agent shows caching progress, the display of some sort
of user interface indicating to the user that the user agent is
checking for the availability of updates.
Fetching the manifest: Fetch the resource from manifest URL with the synchronous flag set, and let manifest be that resource. HTTP caching semantics should be honored for this request.
Parse manifest according to the rules for parsing manifests, obtaining a list of explicit entries, fallback entries and the fallback namespaces that map to them, entries for the online whitelist, and a value for the online whitelist wildcard flag.
The MIME type of the resource is
ignored — it is assumed to be
text/cache-manifest
. In the future, if new manifest
formats are supported, the different types will probably be
distinguished on the basis of the file signatures (for the current
format, that is the "CACHE MANIFEST
"
string at the top of the file).
If fetching the manifest fails due to a 404 or 410 response or equivalent, then run these substeps:
Mark cache group as obsolete. This cache group no longer exists for any purpose other
than the processing of Document
objects already
associated with an application cache in the cache group.
Let task list be an empty list of tasks.
For each cache host associated with an
application cache in cache
group, create a task to
fire a simple event named obsolete
that is
cancelable at the ApplicationCache
singleton of the
cache host, and append it to task
list. The default action of these events must be, if the
user agent shows caching progress, the display of
some sort of user interface indicating to the user that the
application is no longer available for offline use.
For each entry in cache group's list of pending master
entries, create a task
to fire a simple event that is cancelable named
error
(not obsolete
!) at the
ApplicationCache
singleton of the
Document
for this entry, if there still is one, and
append it to task list. The default action of
this event must be, if the user agent shows caching
progress, the display of some sort of user interface
indicating to the user that the user agent failed to save the
application for offline use.
If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.
If appropriate, remove any user interface indicating that an update for this cache is in progress.
Let the status of cache group be idle.
For each task in task list, queue that task as a post-load task.
Abort the application cache download process.
Otherwise, if fetching the manifest fails in some other way (e.g. the server returns another 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download, or the parser for manifests fails when checking the magic signature), or if the server returned a redirect, then run the cache failure steps. [HTTP]
If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in the newest application cache in cache group, or the server reported it as "304 Not Modified" or equivalent, then run these substeps:
Let cache be the newest application cache in cache group.
Let task list be an empty list of tasks.
For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.
If the download failed (e.g. the server returns a 4xx or 5xx
response or
equivalent, or there is a DNS error, the connection times
out, or the user cancels the download), or if the resource is
labeled with the "no-store" cache directive, then create a task to fire a simple
event that is cancelable named error
at the
ApplicationCache
singleton of the
Document
for this entry, if there still is one, and
append it to task list. The default action
of this event must be, if the user agent shows caching
progress, the display of some sort of user interface
indicating to the user that the user agent failed to save the
application for offline use.
Otherwise, associate the Document
for this entry
with cache; store the resource for this
entry in cache, if it isn't already there,
and categorize its entry as a master entry. If the
resource's URL has a <fragment> component, it must
be removed from the entry in cache
(application caches never include fragment identifiers).
For each cache host associated with an
application cache in cache
group, create a task to
fire a simple event that is cancelable named noupdate
at the
ApplicationCache
singleton of the cache
host, and append it to task list. The
default action of these events must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that the application is up
to date.
Empty cache group's list of pending master entries.
If appropriate, remove any user interface indicating that an update for this cache is in progress.
Let the status of cache group be idle.
For each task in task list, queue that task as a post-load task.
Abort the application cache download process.
Let new cache be a newly created application cache in cache group. Set its completeness flag to incomplete.
For each entry in cache group's list of pending master
entries, associate the Document
for this entry
with new cache.
Set the status of cache group to downloading.
For each cache host associated with an
application cache in cache group,
queue a post-load task to fire a simple
event that is cancelable named downloading
at the
ApplicationCache
singleton of the cache
host. The default action of these events must be, if the
user agent shows caching progress, the display of some
sort of user interface indicating to the user that a new version is
being downloaded.
Let file list be an empty list of URLs with flags.
Add all the URLs in the list of explicit entries obtained by parsing manifest to file list, each flagged with "explicit entry".
Add all the URLs in the list of fallback entries obtained by parsing manifest to file list, each flagged with "fallback entry".
If this is an upgrade attempt, then add all the URLs of master entries in the newest application cache in cache group whose completeness flag is complete to file list, each flagged with "master entry".
If any URL is in file list more than once, then merge the entries into one entry for that URL, that entry having all the flags that the original entries had.
For each URL in file list, run the
following steps. These steps may be run in parallel for two or
more of the URLs at a time. If, while running these steps, the
ApplicationCache
object's abort()
method sends a signal to this instance of the
application cache download process algorithm, then
run the cache failure steps instead.
If the resource URL being processed was flagged as neither an "explicit entry" nor or a "fallback entry", then the user agent may skip this URL.
This is intended to allow user agents to expire resources not listed in the manifest from the cache. Generally, implementors are urged to use an approach that expires lesser-used resources first.
For each cache host associated with an
application cache in cache
group, queue a post-load task to fire an event
with the name progress
, which does not
bubble, which is cancelable, and which uses the
ProgressEvent
interface, at the
ApplicationCache
singleton of the cache
host. The lengthComputable
attribute must be set to true, the total
attribute must be
set to the number of files in file list, and
the loaded
attribute must be set to the number of files in file list that have been either downloaded or
skipped so far. The default action of these events must be, if
the user agent shows caching progress, the display
of some sort of user interface indicating to the user that a file
is being downloaded in preparation for updating the application.
[PROGRESS]
Fetch the resource, from the origin of the URL manifest URL, with the synchronous flag set and the manual redirect flag set. If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache. User agents may also have other caches in place that are also honored.
If the resource in question is already being downloaded for other reasons then the existing download process can sometimes be used for the purposes of this step, as defined by the fetching algorithm.
An example of a resource that might already
be being downloaded is a large image on a Web page that is being
seen for the first time. The image would get downloaded to
satisfy the img
element on the page, as well as
being listed in the cache manifest. According to the rules for
fetching that image only need be
downloaded once, and it can be used both for the cache and for
the rendered Web page.
If the previous step fails (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download), or if the server returned a redirect, or if the resource is labeled with the "no-store" cache directive, then run the first appropriate step from the following list: [HTTP]
If these steps are being run in parallel for any other URLs in file list, then abort these steps for those other URLs. Run the cache failure steps.
Redirects are fatal because they are either indicative of a network problem (e.g. a captive portal); or would allow resources to be added to the cache under URLs that differ from any URL that the networking model will allow access to, leaving orphan entries; or would allow resources to be stored under URLs different than their true URLs. All of these situations are bad.
Skip this resource. It is dropped from the cache.
Copy the resource and its metadata from the newest application cache in cache group whose completeness flag is complete, and act as if that was the fetched resource, ignoring the resource obtained from the network.
User agents may warn the user of these errors as an aid to development.
These rules make errors for resources listed in the manifest fatal, while making it possible for other resources to be removed from caches when they are removed from the server, without errors, and making non-manifest resources survive server-side errors.
Except for the "no-store" directive, HTTP caching rules that would cause a file to be expired or otherwise not cached are ignored for the purposes of the application cache download process.
Otherwise, the fetching succeeded. Store the resource in the new cache.
If the user agent is not able to store the resource (e.g. because of quota restrictions), the user agent may prompt the user or try to resolve the problem in some other manner (e.g. automatically pruning content in other caches). If the problem cannot be resolved, the user agent must run the cache failure steps.
If the URL being processed was flagged as an "explicit entry" in file list, then categorize the entry as an explicit entry.
If the URL being processed was flagged as a "fallback entry" in file list, then categorize the entry as a fallback entry.
If the URL being processed was flagged as an "master entry" in file list, then categorize the entry as a master entry.
As an optimization, if the resource is an HTML or XML file
whose root element is an html
element with a manifest
attribute whose value
doesn't match the manifest URL of the application cache being
processed, then the user agent should mark the entry as being
foreign.
For each cache host associated with an
application cache in cache group,
queue a post-load task to fire an event with the name
progress
, which does
not bubble, which is cancelable, and which uses the
ProgressEvent
interface, at the
ApplicationCache
singleton of the cache
host. The lengthComputable
attribute must be set to true, the total
and the loaded
attributes must be
set to the number of files in file list. The
default action of these events must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that all the files have been
downloaded. [PROGRESS]
Store the list of fallback namespaces, and the URLs of the fallback entries that they map to, in new cache.
Store the URLs that form the new online whitelist in new cache.
Store the value of the new online whitelist wildcard flag in new cache.
For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.
If the download failed (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, the connection times out, or the user cancels the download), or if the resource is labeled with the "no-store" cache directive, then run these substeps:
Unassociate the Document
for this entry from
new cache.
Queue a post-load task to fire a simple
event that is cancelable named error
at the
ApplicationCache
singleton of the
Document
for this entry, if there still is one. The
default action of this event must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that the user agent failed
to save the application for offline use.
If this is a cache attempt and this entry is the last entry in cache group's list of pending master entries, then run these further substeps:
Discard cache group and its only application cache, new cache.
If appropriate, remove any user interface indicating that an update for this cache is in progress.
Abort the application cache download process.
Otherwise, remove this entry from cache group's list of pending master entries.
Otherwise, store the resource for this entry in new cache, if it isn't already there, and categorize its entry as a master entry.
Fetch the resource from manifest URL again, with the synchronous flag set, and let second manifest be that resource. HTTP caching semantics should again be honored for this request.
Since caching can be honored, authors are encouraged to avoid setting the cache headers on the manifest in such a way that the user agent would simply not contact the network for this second request; otherwise, the user agent would not notice if the cache had changed during the cache update process.
If the previous step failed for any reason, or if the fetching attempt involved a redirect, or if second manifest and manifest are not byte-for-byte identical, then schedule a rerun of the entire algorithm with the same parameters after a short delay, and run the cache failure steps.
Otherwise, store manifest in new cache, if it's not there already, and categorize its entry as the manifest.
Set the completeness flag of new cache to complete.
Let task list be an empty list of tasks.
If this is a cache
attempt, then for each cache host associated
with an application cache in cache
group, create a task to
fire a simple event that is cancelable named cached
at the
ApplicationCache
singleton of the cache
host, and append it to task list. The
default action of these events must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that the application has
been cached and that they can now use it offline.
Otherwise, it is an upgrade attempt. For each
cache host associated with an application
cache in cache group, create a task to fire a simple
event that is cancelable named updateready
at the
ApplicationCache
singleton of the cache
host, and append it to task list. The
default action of these events must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that a new version is
available and that they can activate it by reloading the page.
If appropriate, remove any user interface indicating that an update for this cache is in progress.
Set the update status of cache group to idle.
For each task in task list, queue that task as a post-load task.
The cache failure steps are as follows:
Let task list be an empty list of tasks.
For each entry in cache group's list of pending master entries, run the following further substeps. These steps may be run in parallel for two or more entries at a time.
Wait for the resource for this entry to have either completely downloaded or failed.
Unassociate the Document
for this entry from
its application cache, if it has one.
Create a task to
fire a simple event that is cancelable named error
at the
ApplicationCache
singleton of the
Document
for this entry, if there still is one, and
append it to task list. The default action of
these events must be, if the user agent shows caching
progress, the display of some sort of user interface
indicating to the user that the user agent failed to save the
application for offline use.
For each cache host still associated with an
application cache in cache group,
create a task to fire a
simple event that is cancelable named error
at the
ApplicationCache
singleton of the cache
host, and append it to task list. The
default action of these events must be, if the user agent
shows caching progress, the display of some sort of
user interface indicating to the user that the user agent failed to
save the application for offline use.
Empty cache group's list of pending master entries.
If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.
If appropriate, remove any user interface indicating that an update for this cache is in progress.
Let the status of cache group be idle.
If this was a cache attempt, discard cache group altogether.
For each task in task list, queue that task as a post-load task.
Abort the application cache download process.
Attempts to fetch resources as part of the application cache download process may be done with cache-defeating semantics, to avoid problems with stale or inconsistent intermediary caches.
User agents may invoke the application cache download process, in the background, for any application cache, at any time (with no cache host). This allows user agents to keep caches primed and to update caches even before the user visits a site.
Each Document
has a list of pending application
cache download process tasks that is used to delay events
fired by the algorithm above until the document's load
event has fired. When the
Document
is created, the list must be empty.
When the steps above say to queue a post-load task
task, where task is a task that dispatches an event on a
target ApplicationCache
object target, the user agent must run the appropriate steps
from the following list:
Document
is
ready for post-load tasksQueue the task task.
Add task to target's
Document
's list of pending application cache
download process tasks.
The task source for these tasks is the networking task source.
When the application cache
selection algorithm algorithm is invoked with a
Document
document and optionally a
manifest URL manifest URL, the user
agent must run the first applicable set of steps from the following
list:
Mark the entry for the resource from which document was taken in the application cache from which it was loaded as foreign.
Restart the current navigation from the top of the navigation algorithm, undoing any changes that were made as part of the initial load (changes can be avoided by ensuring that the step to update the session history with the new page is only ever completed after this application cache selection algorithm is run, though this is not required).
The navigation will not result in the same resource being loaded, because "foreign" entries are never picked during navigation.
User agents may notify the user of the inconsistency between the cache manifest and the document's own metadata, to aid in application development.
Associate document with the application cache from which it was loaded. Invoke, in the background, the application cache download process for that application cache's application cache group, with document as the cache host.
Invoke, in the background, the application cache download process for manifest URL, with document as the cache host and with the resource from which document was parsed as the master resource.
The Document
is not associated with any
application cache.
If there was a manifest URL, the user agent may report to the user that it was ignored, to aid in application development.
When a cache host is associated with an application cache whose completeness flag is complete, any and all loads for resources related to that cache host other than those for child browsing contexts must go through the following steps instead of immediately invoking the mechanisms appropriate to that resource's scheme:
If the resource is not to be fetched using the HTTP GET mechanism or equivalent, or if its URL has a different <scheme> component than the application cache's manifest, then fetch the resource normally and abort these steps.
If the resource's URL is a master entry, the manifest, an explicit entry, or a fallback entry in the application cache, then get the resource from the cache (instead of fetching it), and abort these steps.
If there is an entry in the application cache's online whitelist that has the same origin as the resource's URL and that is a prefix match for the resource's URL, then fetch the resource normally and abort these steps.
If the resource's URL has the same origin as the manifest's URL, and there is a fallback namespace f in the application cache that is a prefix match for the resource's URL, then:
Fetch the resource normally. If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps.
If the application cache's online whitelist wildcard flag is open, then fetch the resource normally and abort these steps.
Fail the resource load as if there had been a generic network error.
The above algorithm ensures that so long as the online whitelist wildcard flag is blocking, resources that are not present in the manifest will always fail to load (at least, after the application cache has been primed the first time), making the testing of offline applications simpler.
As a general rule, user agents should not expire application caches, except on request from the user, or after having been left unused for an extended period of time.
Application caches and cookies have similar implications with respect to privacy (e.g. if the site can identify the user when providing the cache, it can store data in the cache that can be used for cookie resurrection). Implementors are therefore encouraged to expose application caches in a manner related to HTTP cookies, allowing caches to be expunged together with cookies and other origin-specific data.
For example, a user agent could have a "delete site-specific data" feature that clears all cookies, application caches, local storage, databases, etc, from an origin all at once.
User agents should consider applying constraints on disk usage of application caches, and care should be taken to ensure that the restrictions cannot be easily worked around using subdomains.
User agents should allow users to see how much space each domain is using, and may offer the user the ability to delete specific application caches.
How quotas are presented to the user is not defined by this specification. User agents are encouraged to provide features such as allowing a user to indicate that certain sites are trusted to use more than the default quota, e.g. by asynchronously presenting a user interface while a cache is being updated, or by having an explicit whitelist in the user agent's configuration interface.
interface ApplicationCache : EventTarget { // update status const unsigned short UNCACHED = 0; const unsigned short IDLE = 1; const unsigned short CHECKING = 2; const unsigned short DOWNLOADING = 3; const unsigned short UPDATEREADY = 4; const unsigned short OBSOLETE = 5; readonly attribute unsigned short status; // updates void update(); void abort(); void swapCache(); // events [TreatNonCallableAsNull] attribute Function? onchecking; [TreatNonCallableAsNull] attribute Function? onerror; [TreatNonCallableAsNull] attribute Function? onnoupdate; [TreatNonCallableAsNull] attribute Function? ondownloading; [TreatNonCallableAsNull] attribute Function? onprogress; [TreatNonCallableAsNull] attribute Function? onupdateready; [TreatNonCallableAsNull] attribute Function? oncached; [TreatNonCallableAsNull] attribute Function? onobsolete; };
applicationCache
(In a window.) Returns the ApplicationCache
object that applies to the active document of that Window
.
applicationCache
(In a shared worker.) Returns the ApplicationCache
object that applies to the current shared worker.
[WEBWORKERS]
status
Returns the current status of the application cache, as given by the constants defined below.
update
()Invokes the application cache download process.
Throws an InvalidStateError
exception if there is no application cache to update.
Calling this method is not usually necessary, as user agents will generally take care of updating application caches automatically.
The method can be useful in situations such as long-lived applications. For example, a Web mail application might stay open in a browser tab for weeks at a time. Such an application could want to test for updates each day.
abort
()Cancels the application cache download process.
This method is intended to be used by Web application showing their own caching progress UI, in case the user wants to stop the update (e.g. because bandwidth is limited).
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 swapCache()
is just to
reload the entire page at a time suitable for the user, using
location.reload()
.
There is a one-to-one mapping from cache
hosts to ApplicationCache
objects. The applicationCache
attribute on Window
objects must return the
ApplicationCache
object associated with the
Window
object's active document. The applicationCache
attribute on SharedWorkerGlobalScope
objects must
return the ApplicationCache
object associated with the
worker.
[WEBWORKERS]
A Window
or
SharedWorkerGlobalScope
object has an associated
ApplicationCache
object even if that cache
host has no actual application cache.
The status
attribute, on getting, must return the current state of the
application cache that the
ApplicationCache
object's cache host is
associated with, if any. This must be the appropriate value from the
following list:
UNCACHED
(numeric value 0)The ApplicationCache
object's cache
host is not associated with an application
cache at this time.
IDLE
(numeric value 1)The ApplicationCache
object's cache
host is associated with an application cache
whose application cache group's update status is
idle, and that application cache is the newest cache in its
application cache group, and the application
cache group is not marked as obsolete.
CHECKING
(numeric value 2)The ApplicationCache
object's cache
host is associated with an application cache
whose application cache group's update status is
checking.
DOWNLOADING
(numeric value 3)The ApplicationCache
object's cache
host is associated with an application cache
whose application cache group's update status is
downloading.
UPDATEREADY
(numeric value 4)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.
OBSOLETE
(numeric value 5)The ApplicationCache
object's cache
host is associated with an application cache
whose application cache group is marked as obsolete.
If the update()
method is
invoked, the user agent must invoke the application cache
download process, in the background, for the application
cache with which the ApplicationCache
object's
cache host is associated, but without giving that
cache host to the algorithm. If there is no such
application cache, or if it is marked as obsolete, then the method
must throw an InvalidStateError
exception instead.
If the abort()
method is invoked, the user agent must send a signal to
the current application cache download process for the
application cache with which the
ApplicationCache
object's cache host is
associated, if any. If there is no such application
cache, or it does not have a current application cache
download process, then do nothing.
If the swapCache()
method
is invoked, the user agent must run the following steps:
Check that ApplicationCache
object's
cache host is associated with an application
cache. If it is not, then throw an
InvalidStateError
exception and abort these
steps.
Let cache be the application
cache with which the ApplicationCache
object's
cache host is associated. (By definition, this is the
same as the one that was found in the previous step.)
If cache's application cache
group is marked as obsolete, then unassociate
the ApplicationCache
object's cache host
from cache and abort these steps. (Resources
will now load from the network instead of the cache.)
Check that there is an application cache in the same
application cache group as cache
whose completeness
flag is complete and that is newer than cache. If there is not, then throw an
InvalidStateError
exception and abort these
steps.
Let new cache be the newest application cache in the same application cache group as cache whose completeness flag is complete.
Unassociate the ApplicationCache
object's
cache host from cache and instead
associate it with new cache.
The following are the event handlers (and their
corresponding event handler
event types) that must be supported, as IDL attributes, by
all objects implementing the ApplicationCache
interface:
Event handler | Event handler event type |
---|---|
onchecking | checking
|
onerror | error
|
onnoupdate | noupdate
|
ondownloading | downloading
|
onprogress | progress
|
onupdateready | updateready
|
oncached | cached
|
onobsolete | obsolete
|
[NoInterfaceObject] interface NavigatorOnLine { readonly attribute boolean onLine; };
navigator
. onLine
Returns false if the user agent is definitely offline (disconnected from the network). Returns true if the user agent might be online.
The events online
and offline
are fired when the value of
this attribute changes.
The navigator.onLine
attribute must return false if the user agent will not contact the
network when the user follows links or when a script requests a
remote page (or knows that such an attempt would fail), and must
return true otherwise.
When the value that would be returned by the navigator.onLine
attribute of a
Window
or WorkerGlobalScope
changes from
true to false, the user agent must queue a task to
fire a simple event named offline
at the
Window
or WorkerGlobalScope
object.
On the other hand, when the value that would be returned by the
navigator.onLine
attribute
of a Window
or WorkerGlobalScope
changes
from false to true, the user agent must queue a task to
fire a simple event named online
at the
Window
or WorkerGlobalScope
object.
The task source for these tasks is the networking task source.
This attribute is inherently unreliable. A computer can be connected to a network without having Internet access.
In this example, an indicator is updated as the browser goes online and offline.
<!DOCTYPE HTML> <html> <head> <title>Online status</title> <script> function updateIndicator() { document.getElementById('indicator').textContent = navigator.onLine ? 'online' : 'offline'; } </script> </head> <body onload="updateIndicator()" ononline="updateIndicator()" onoffline="updateIndicator()"> <p>The network is: <span id="indicator">(state unknown)</span> </body> </html>