Support: offline-apps Chrome for Android 67+ Chrome 4+ iOS Safari 3.2+ UC Browser for Android 11.8+ Firefox 3.5+ IE 10+ Opera Mini None Safari 4+ Edge 12+ Samsung Internet 4+ Opera 10.6+ Android Browser 2.1+
Source: caniuse.com
This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use service workers instead. [SW]
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
"
clock1.html
",
a
CSS
style
sheet
"
clock.css
",
and
a
JavaScript
script
"
clock.js
".
Before adding the manifest, these three files might look like this:
EXAMPLE
offline/clock/clock1.html
EXAMPLE
offline/clock/clock.css
EXAMPLE
offline/clock/clock.js
If
the
user
tries
to
open
the
"
clock1.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
":
EXAMPLE offline/clock/clock.appcache
With
a
small
change
to
the
HTML
file,
the
manifest
(served
as
text/cache-manifest
)
is
linked
to
the
application:
EXAMPLE
offline/clock/clock2.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.
The
application
cache
feature
works
best
if
the
application
logic
is
separate
from
the
application
and
user
data,
with
the
logic
(markup,
scripts,
style
sheets,
images,
etc)
listed
in
the
manifest
and
stored
in
the
application
cache,
with
a
finite
number
of
static
HTML
pages
for
the
application,
and
with
the
application
and
user
data
stored
in
Web
Storage
or
a
client-side
Indexed
Database,
updated
dynamically
using
Web
Sockets,
XMLHttpRequest
,
server-sent
events,
or
some
other
similar
mechanism.
This model results in a fast experience for the user: the application immediately loads, and fresh data is obtained as fast as the network will allow it (possibly while stale data shows).
Legacy applications, however, tend to be designed so that the user data and the logic are mixed together in the HTML, with each operation resulting in a new HTML page from the server.
For example, consider a news application. The typical architecture of such an application, when not using the application cache feature, is that the user fetches the main page, and the server returns a dynamically-generated page with the current headlines and the user interface logic mixed together.
A
news
application
designed
for
the
application
cache
feature,
however,
would
instead
have
the
main
page
just
consist
of
the
logic,
and
would
then
have
the
main
page
fetch
the
data
separately
from
the
server,
e.g.
using
XMLHttpRequest
.
The mixed-content model does not work well with the application cache feature: since the content is cached, it would result in the user always seeing the stale data from the previous time the cache was updated.
While
there
is
no
way
to
make
the
legacy
model
work
as
fast
as
the
separated
model,
it
can
at
least
be
retrofitted
for
offline
use
using
the
prefer-online
application
cache
mode
.
To
do
so,
list
all
the
static
resources
used
by
the
HTML
page
you
want
to
have
work
offline
in
an
application
cache
manifest
,
use
the
manifest
attribute
to
select
that
manifest
from
the
HTML
file,
and
then
add
the
following
line
at
the
bottom
of
the
manifest:
SETTINGS: prefer-online NETWORK: *
This causes the application cache to only be used for master entries when the user is offline, and causes the application cache to be used as an atomic HTTP cache (essentially pinning resources listed in the manifest), while allowing all resources not listed in the manifest to be accessed normally when the user is online.
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.
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.
|
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. |
These events are cancelable; their default action is for the user agent to show download progress information. If the page shows its own update UI, canceling the events will prevent the user agent from showing redundant progress information.
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 safelist 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 local HTTP cache as appropriate).
An online safelist 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 safelist namespaces ; the blocking state indicates that URLs not listed explicitly in the manifest are to be treated as unavailable.
A cache mode flag , which is either in the fast state or the prefer-online state.
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
object.
Each
cache
host
has
an
associated
ApplicationCache
object.
Each cache host 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.
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
https://example.com/app1/manifest
declares
that
https://example.com/resources/images
is
a
fallback
namespace,
and
the
user
navigates
to
https://example.com:80/resources/images/cat.png
,
then
the
user
agent
will
decide
that
the
application
cache
identified
by
https://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 safelists 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 safelist -- 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 https://img.example.com/logo.png https://img.example.com/check.png https://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 safelist 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 U+000A LINE FEED (LF) characters, U+000D CARRIAGE RETURN (CR) characters, or U+000D CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs. [ENCODING]
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 U+0009 CHARACTER TABULATION (tab) character, a U+000A LINE FEED (LF) character, or a U+000D CARRIAGE RETURN (CR) character. The first line may optionally be preceded by a U+FEFF BYTE ORDER MARK (BOM) 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 U+0009 CHARACTER TABULATION (tab) characters only.
Comment lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, followed by a single U+0023 NUMBER SIGN character (#), followed by zero or more characters other than U+000A LINE FEED (LF) and U+000D CARRIAGE RETURN (CR) characters.
Comments need to 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 .
Section headers change the current section. There are four possible section headers:
CACHE:
FALLBACK:
NETWORK:
SETTINGS:
Section header lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, followed by one of the names above (including the U+003A COLON character (:)) followed by zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) 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 U+0009 CHARACTER TABULATION (tab) characters, a valid URL string identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.
When the current section is the fallback section , data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, a valid URL string identifying a resource other than the manifest itself, one or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, another valid URL string identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.
When the current section is the online safelist section , data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, either a single U+002A ASTERISK character (*) or a valid URL string identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.
When the current section is the settings section , data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, a setting , and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.
Currently only one setting is defined:
prefer-online
".
It
sets
the
cache
mode
to
prefer-online
.
(The
cache
mode
defaults
to
fast
.)
Within a settings section , each setting must occur no more than once.
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. Fallback namespaces must also be in the same path as the manifest's URL.
A fallback namespace must not be listed more than once.
Namespaces that the user agent is to put into the online safelist must all be specified in online safelist 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 safelisted in this way, a U+002A ASTERISK character (*) may be specified as one of the URLs.
Authors should not include namespaces in the online safelist for which another namespace in the online safelist 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 ). [URL]
URLs in manifests must not have fragments (i.e. the U+0023 NUMBER SIGN character isn't allowed in URLs in manifests).
Fallback namespaces and namespaces in the online safelist 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:
UTF-8 decode the byte stream corresponding with the manifest to be parsed.
The UTF-8 decode algorithm strips a leading BOM, if any.
Let base URL be the absolute URL representing the manifest.
Apply the URL parser to base URL , and let manifest path be the path component thus obtained.
Remove all the characters in manifest path after the last U+002F SOLIDUS character (/), if any. (The first character and the last character in manifest path after this step will both be slashes, the URL path separator character.)
Apply the URL parser steps to the base URL , so that the components from its URL record can be used by the subsequent steps of this algorithm.
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 safelist namespaces be an initially empty list of absolute URLs for an online safelist .
Let online safelist wildcard flag be blocking .
Let cache mode flag be fast .
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 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; return with a failure while checking for the magic signature.
If the character at position is neither a U+0020 SPACE character, a U+0009 CHARACTER TABULATION (tab) character, U+000A LINE FEED (LF) character, nor a U+000D CARRIAGE RETURN (CR) character, then this isn't a cache manifest; return 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 code points that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters from input given position , 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 code points that are U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), U+0020 SPACE, or U+0009 CHARACTER TABULATION (tab) characters from input given position .
Now, collect a sequence of code points that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters from input given position , and let the result be line .
Drop any trailing U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) 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 NUMBER SIGN character (#), then jump back to the step labeled start of line .
If line equals "CACHE:" (the word "CACHE" followed by a U+003A COLON 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 COLON 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 COLON character (:)), then set mode to "online safelist" and jump back to the step labeled start of line .
If line equals "SETTINGS:" (the word "SETTINGS" followed by a U+003A COLON character (:)), then set mode to "settings" and jump back to the step labeled start of line .
If line ends with a U+003A COLON 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 U+0009 CHARACTER TABULATION (tab) 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 U+0009 CHARACTER TABULATION (tab) character, advance position to the next character in input .
Process tokens as follows:
Let urlRecord be the result of parsing the first item in tokens with base URL ; ignore the rest.
If urlRecord is failure, then jump back to the step labeled start of line .
If urlRecord has a different scheme component than base URL (the manifest's URL), then jump back to the step labeled start of line .
Let new URL be the result of applying the URL serializer algorithm to urlRecord , with the exclude fragment flag set.
Add new URL to the explicit URLs .
Let part one be the first token in tokens , and let part two be the second token in tokens .
Let urlRecordOne be the result of parsing part one with base URL .
Let urlRecordTwo be the result of parsing part two with base URL .
If either urlRecordOne or urlRecordTwo are failure, then jump back to the step labeled start of line .
If the origin of either urlRecordOne or urlRecordTwo is not same origin with the manifest's URL origin , then jump back to the step labeled start of line .
Let part one path be the path component of urlRecordOne .
If manifest path is not a prefix match for part one path , then jump back to the step labeled start of line .
Let part one be the result of applying the URL serializer algorithm to urlRecordOne , with the exclude fragment flag set.
Let part two be the result of applying the URL serializer algorithm to urlRecordTwo , with the exclude fragment flag set.
If 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 part one to the fallback URLs mapping as a fallback namespace , mapped to part two as the fallback entry .
If the first item in tokens is a U+002A ASTERISK character (*), then set online safelist wildcard flag to open and jump back to the step labeled start of line .
Otherwise, let urlRecord be the result of parsing the first item in tokens with base URL .
If urlRecord is failure, then jump back to the step labeled start of line .
If urlRecord has a different scheme component than base URL (the manifest's URL), then jump back to the step labeled start of line .
Let new URL be the result of applying the URL serializer algorithm to urlRecord , with the exclude fragment flag set.
Add new URL to the online safelist namespaces .
If
tokens
contains
a
single
token,
and
that
token
is
a
case-sensitive
match
for
the
string
"
prefer-online
",
then
set
cache
mode
flag
to
prefer-online
and
jump
back
to
the
step
labeled
start
of
line
.
Otherwise, the line is an unsupported setting: do nothing; the line is ignored.
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 safelist namespaces , the online safelist wildcard flag , and the cache mode 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
safelist
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 safelist namespaces .
When a fallback namespace and an online safelist namespace overlap, the online safelist namespace has priority.
The online safelist wildcard flag is applied last, only for URLs that match neither the online safelist 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 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.
(Such
events
are
delayed
until
after
the
load
event
has
fired.)
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.
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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
checking
at
the
ApplicationCache
singleton
of
that
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
downloading
at
the
ApplicationCache
singleton
of
that
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
checking
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 in parallel .
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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
checking
at
the
ApplicationCache
singleton
of
that
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display some sort of user interface indicating to the user that the user agent is checking for the availability of updates.
Let
request
be
a
new
request
whose
url
is
manifest
URL
,
client
is
null,
destination
is
the
empty
string,
referrer
is
"
no-referrer
",
synchronous
flag
is
set,
credentials
mode
is
"
include
",
and
whose
use-URL-credentials
flag
is
set.
Fetching the manifest : Let manifest be the result of fetching request . HTTP caching semantics should be honored for this request.
Parse manifest 's body 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 safelist , and values for the online safelist wildcard flag and the cache mode 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 status, 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
obsolete
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
error
(not
obsolete
!)
at
the
ApplicationCache
singleton
of
the
Document
for
this
entry,
if
there
still
is
one,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 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
response
status
is
304
,
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 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
error
at
the
ApplicationCache
singleton
of
the
Document
for
this
entry,
if
there
still
is
one,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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
applying
the
URL
parser
algorithm
to
the
resource's
URL
results
in
a
URL
record
that
has
a
non-null
fragment
component,
the
URL
used
for
the
entry
in
cache
must
instead
be
the
absolute
URL
obtained
from
applying
the
URL
serializer
algorithm
to
the
URL
record
with
the
exclude
fragment
flag
set
(application
caches
never
include
fragments
).
For each cache host associated with an application cache in cache group , create a task to run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
noupdate
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
downloading
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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, implementers 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 progress post-load task to run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
progress
at
the
ApplicationCache
singleton
of
the
cache
host
,
using
ProgressEvent
,
with
the
cancelable
attribute
initialized
to
true,
the
lengthComputable
attribute
initialized
to
true,
the
total
attribute
initialized
to
the
number
of
files
in
file
list
,
and
the
loaded
attribute
initialized
to
the
number
of
files
in
file
list
that
have
been
either
downloaded
or
skipped
so
far.
[XHR]
If showProgress is true and the user agent shows caching progress , then display some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application.
Let
request
be
a
new
request
whose
url
is
URL,
client
is
null,
destination
is
the
empty
string,
origin
is
manifest
URL
's
origin
,
referrer
is
"
no-referrer
",
synchronous
flag
is
set,
credentials
mode
is
"
include
",
use-URL-credentials
flag
is
set,
and
redirect
mode
is
"
manual
".
Fetch request . 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 previous step fails (e.g. the server returns a 4xx or 5xx response, 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 this algorithm 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
document
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 progress post-load task to run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
progress
at
the
ApplicationCache
singleton
of
the
cache
host
,
using
ProgressEvent
,
with
the
cancelable
attribute
initialized
to
true,
the
lengthComputable
attribute
initialized
to
true,
and
the
total
and
loaded
attributes
initialized
to
the
number
of
files
in
file
list
.
[XHR]
If showProgress is true and the user agent shows caching progress , then display some sort of user interface indicating to the user that all the files have been downloaded.
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 safelist in new cache .
Store the value of the new online safelist wildcard flag in new cache .
Store the value of the new cache mode 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 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 run these steps:
Let
showProgress
be
the
result
of
firing
an
event
named
error
at
the
ApplicationCache
singleton
of
the
Document
for
this
entry,
if
there
still
is
one,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 .
Let
request
be
a
new
request
whose
url
is
manifest
URL
,
client
is
null,
destination
is
the
empty
string,
referrer
is
"
no-referrer
",
synchronous
flag
is
set,
credentials
mode
is
"
include
",
and
whose
use-URL-credentials
flag
is
set.
Let second manifest be the result of fetching request . 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
cached
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
updateready
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
error
at
the
ApplicationCache
singleton
of
the
Document
for
this
entry,
if
there
still
is
one,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 run these steps and append it to task list :
Let
showProgress
be
the
result
of
firing
an
event
named
error
at
the
ApplicationCache
singleton
of
the
cache
host
,
with
the
cancelable
attribute
initialized
to
true.
If showProgress is true and the user agent shows caching progress , then display 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 group , 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:
Queue the task task .
Add task to target 's node document 's list of pending application cache download process tasks .
When
the
steps
above
say
to
queue
a
progress
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
following
steps:
If there is a task in target 's node document 's list of pending application cache download process tasks that is labeled as a progress task , then remove that task from the list.
Label task as a progress task .
Queue a post-load task task .
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 .
GET
`,
and,
there
is
a
manifest
URL
,
and
manifest
URL
has
the
same
origin
as
document
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.
If there are relevant application caches that are identified by a URL with the same origin as the URL of document , and that have this URL as one of their entries, excluding entries marked as foreign , then the user agent should use the most appropriate application cache of those that match as an HTTP cache for any subresource loads. User agents may also have other caches in place that are also honored.
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.
If "AppCache" is not removed as a feature this section needs to be integrated into the Fetch standard.
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 GET method, or if applying the URL parser algorithm to both its URL and the application cache 's manifest 's URL results in two URL records with different scheme components, then fetch the resource normally and return.
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 return.
If there is an entry in the application cache 's online safelist 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 return.
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 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 . Return.
If the application cache 's online safelist wildcard flag is open , then fetch the resource normally and return.
Fail the resource load as if there had been a generic network error.
The above algorithm ensures that so long as the online safelist 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 .
For predictability, quotas should be based on the uncompressed size of data stored.
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 presenting a non-modal user interface while a cache is being updated, or by having an explicit safelist in the user agent's configuration interface.
This section is non-normative.
The main risk introduced by offline application caches is that an injection attack can be elevated into persistent site-wide page replacement. This attack involves using an injection vulnerability to upload two files to the victim site. The first file is an application cache manifest consisting of just a fallback entry pointing to the second file, which is an HTML page whose manifest is declared as that first file. Once the user has been directed to that second file, all subsequent accesses to any file covered by the given fallback namespace while either the user or the site is offline will instead show that second file. Targeted denial-of-service attacks or cookie bombing attacks (where the client is made to send so many cookies that the server refuses to process the request) can be used to ensure that the site appears offline.
To mitigate this, manifests can only specify fallbacks that are in the same path as the manifest itself. This means that a content injection upload vulnerability in a particular directory on a server can only be escalated to a take-over of that directory and its subdirectories. If there is no way to inject a file into the root directory, the entire site cannot be taken over.
If a site has been attacked in this way, simply removing the offending manifest might eventually clear the problem, since the next time the manifest is updated, a 404 error will be seen, and the user agent will clear the cache. "Eventually" is the key word here, however; while the attack on the user or server is ongoing, such that connections from an affected user to the affected site are blocked, the user agent will simply assume that the user is offline and will continue to use the hostile manifest. Unfortunately, if a cookie bombing attack has also been used, merely removing the manifest is insufficient; in addition, the server has to be configured to return a 404 or 410 response instead of the 413 "Request Entity Too Large" response.
TLS does not inherently protect a site from this attack, since the attack relies on content being served from the server itself. Not using application caches also does not prevent this attack, since the attack relies on an attacker-provided manifest.
[Exposed=Window]
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
attribute EventHandler onchecking;
attribute EventHandler onerror;
attribute EventHandler onnoupdate;
attribute EventHandler ondownloading;
attribute EventHandler onprogress;
attribute EventHandler onupdateready;
attribute EventHandler oncached;
attribute EventHandler onobsolete;
};
applicationCache
Returns
the
ApplicationCache
object
that
applies
to
the
active
document
of
that
Window
.
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
"
DOMException
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
"
DOMException
.
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
.
A
Document
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
group
of
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
its
application
cache
group
is
marked
as
obsolete
,
then
the
method
must
throw
an
"
InvalidStateError
"
DOMException
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
group
of
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
"
DOMException
.
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
return.
(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
"
DOMException
exception.
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
event
handler
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
|
Support: online-status Chrome for Android 67+ Chrome 14+ iOS Safari 4.2+ UC Browser for Android 11.8+ Firefox 41+ IE 9+ Opera Mini None Safari 5+ Edge 12+ Samsung Internet 4+ Opera 15+ Android Browser 2.3+
Source: caniuse.com
interface mixin 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
an
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
an
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 lang="en">
<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>