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.
为了使用户在网络连接不可用时，仍然继续与 Web 应用和文档交互 — 例如， 因为他们在其 ISP 覆盖外旅行时 — 作者可以提供一个清单，列出 Web 应用离线工作需要的文件列表， 用户的浏览器保存一份文件拷贝来供离线使用。
举个例子，考虑一个简单的时钟应用包括一个，HTML 页面 "clock1.html", 一个 CSS 样式表 "clock.css"，和一个
JavaScript 脚本 "clock.js"。
在添加清单之前，这些文件可能看起来像这样：
<!-- clock1.html --> <!DOCTYPE HTML> <html lang="en"> <head> <meta charset="utf-8"> <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 */
setInterval(function () {
document.getElementById('clock').value = new Date();
}, 1000);
如果用户在离线时尝试打开 "clock1.html" 页面，
用户代理（除非恰好它仍然在本地缓存里）将会失败。
作者可以提供一个这3个文件的清单，比如叫 "clock.appcache"：
CACHE MANIFEST clock2.html clock.css clock.js
稍微改动一下 HTML 文件，把清单（作为 text/cache-manifest 服务）
链接到应用：
<!-- clock2.html --> <!DOCTYPE HTML> <html lang="en" manifest="clock.appcache"> <head> <meta charset="utf-8"> <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>
现在，如果用户进入这个页面，浏览器会缓存这些文件并让它们在用户离线时仍然可用。
鼓励作者在清单文件中包含一个主页面，但实践中引用清单文件的页面会被自动缓存， 即使没有显式地提到它。
除了 "no-store" 指令之外，HTTP 缓存头和
TLS（加密的，使用 https:）
上的页面缓存限制都会被清单覆盖。
因此从应用缓存来的页面在用户代理更新它之前不会过期，即使是 TLS 下的应用也可以离线工作。
This section is non-normative.
应用缓存特性的最佳使用状态是应用逻辑与应用和用户数据分离，逻辑（HTML、脚本、样式、图片等）
列在清单里存储到应用缓存，应用的静态 HTML 页面数目是有限的。
应用和用户数据存储在 Web Storage 或客户端 Indexed Database 中，通过
Web Socket、XMLHttpRequest、服务器发送的事件、或其他类似机制动态更新。
利用这一模型可以为用户提供快速的体验：应用瞬间加载（并显示旧数据），网络允许时获取最新数据。
然而历史应用的设计倾向于把用户数据和逻辑混合在 HTML 中，每个操作会从服务器加载整个 HTML 页面。
例如，考虑一个新闻应用。不使用应用缓存特性时，这样的应用典型的架构是， 用户获取主页面，服务器返回一个动态产生的页面，其中混合了当前的头条和用户界面逻辑。
但是为应用缓存特性设计的新闻应用会让主页面只包含逻辑，
在主页面中（比如使用XMLHttpRequest）独立地从服务器获取数据。
混合内容模型不适用于应用程序缓存功能：由于内容被缓存，因此用户总是会看到上次更新缓存时的旧数据。
虽然没办法让遗留的模型与分离模型一样快，但至少
可以 通过 prefer-online
应用缓存模式 让它支持离线使用。
为此，在 拥有缓存清单
中列出 HTML 页面中你希望离线使用的所有静态资源，
在 HTML 文件中通过 manifest
属性来选择清单文件，然后添加下列行到清单底部：
SETTINGS: prefer-online NETWORK: *
这会使 应用缓存 在用户离线时只用于 主入口， 使得应用缓存可以用作原子性的 HTTP 缓存（只对清单中列出的资源有效）， 同时其余没列出的资源当用户在线时可正常访问。
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 primary
entry's html element's manifest attribute.
The manifest is fetched and processed during the application cache download
process. All the primary 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 primary 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 primary 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.
这个示例清单要求缓存两个图片和一个样式表，并把一个 CGI 脚本加入安全列表。
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
下列写法是等效的：
CACHE MANIFEST NETWORK: comm.cgi CACHE: style/default.css images/sound-icon.png images/background.png
离线应用缓存清单可以使用绝对路径，甚至绝对 URL：
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
以下清单定义了一个捕获所有错误的页面，用户离线时用于所有页面的显示。 还指定了在线安全列表通配标志 为 open，意味着不会阻止对外站资源的访问。 （由于捕获所有错误的 fallback 命名空间，站内资源的访问也不会被阻止）
只要站点的所有页面都引用这个清单，它们被获取后就会缓存到本地， 后续访问同一页面时就会立即从缓存加载。 除非清单发生了变化，那些页面不会再从服务器获取。 当清单改变时，所有文件都会重新下载。
但是子资源（比如样式表、图片等）只会使用普通的 HTTP 缓存语义进行缓存。
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 "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 primary 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 primary
resource, then add the resource, along with the resource's Document, to cache group's list of pending
primary 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 primary 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 primary 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 primary 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 primary 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 primary 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 primary entries in the newest application cache in cache group whose completeness flag is complete to file list, each flagged with "primary 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 a "primary entry" in file list, then categorize the entry as a primary 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 primary 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 primary 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 primary entries.
Otherwise, store the resource for this entry in new cache, if it isn't already there, and categorize its entry as a primary 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 primary 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 primary 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.
当使用 Document document
和可选的清单 URL manifest URL
调用 应用缓存选择算法时，
用户代理必须执行如下列表中第一套适当的步骤：
在加载 document 的 应用缓存 中， 标记获取 document 的资源入口为 foreign。
从 导航算法 的头部重启当前导航， 撤销在初次加载过程中的任何改动，（只要确保 使用新的页面更新会话历史 步骤只在该 应用缓存选择算法 执行 之后 完成，就可以避免改动，但不要求这样做）。
导航将会导致加载不同的资源，因为在导航时不会选择 "foreign" 入口。
用户代理可以提示用户缓存清单和文档元数据之间的不一致，来帮助也要开发。
将 document 与加载它的 应用缓存 关联。 为那个 应用缓存 的 应用缓存组 在后台调用 应用缓存下载过程， 使用 document 作为 缓存 Host。
GET` 加载的，
且存在一个 manifest URL，且 manifest URL 与
document为 manifest URL 在后台调用 应用缓存下载过程 使用 document 作为 cache host 使用解析 document 的资源作为 主 资源。
如果存在由 document 同源的 入口 URL 标识的 相关的应用缓存， 排除掉标记为 foreign 的入口， 然后在加载任何子资源时，用户代理应使用匹配为 HTTP 缓存的 最合适的应用缓存。 用户代理也可能有其他缓存，这些缓存也可以用。
如果存在一个 manifest URL，用户代理可以报告用户它已经被忽略，来帮助应用开发。
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 primary 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.
作为通用的规则，用户代理不应该将应用缓存过期，除非受到用户的请求， 或者在很久时间内没有用到。
应用缓存和 Cookie 在隐私方面有同样的意义（例如，如果站点在提供缓存时可以识别用户， 就可以在缓存中存储数据用于 Cookie 恢复）。 因此鼓励实现方以类似 HTTP cookie 的方式暴露应用缓存， 使得缓存可以和 Cookie 等其他域相关的数据一起清除。
例如，一个用户代理可以有一个 "删除站点相关数据" 功能来立即清除 一个域下所有的所有的 Cookie、应用缓存、本地存储、数据库等等。
用户代理应该考虑对 应用缓存 的磁盘用量加以约束， 小心确保这些约束不会被子域名轻易绕过。
用户代理应该允许用户看到每个域名使用的空间大小，也可以为用户提供删除指定 应用缓存 的能力。
为了可预见性，应该根据未压缩的数据大小来进行配额。
如何为用户显示配额不在本规范中定义。 鼓励用户代理提供类似允许用户信任某些站点以使用多于默认的配额，例如在缓存更新时显示一个非模态 UI， 或者在用户代理的配置接口中显示一个安全列表。
This section is non-normative.
离线应用程序缓存引入的主要风险是注入攻击可以提升为持久的站点范围页面替换。 这种攻击涉及使用注入漏洞将两个文件上传到受害者站点。 第一个文件是一个应用程序缓存清单，其中只包含指向第二个文件的 Fallback 入口，该文件是一个HTML 页面，其清单声明为第一个文件。 一旦用户被定向到第二个文件，当用户或站点处于离线状态时，对给定 Fallback 命名空间内的任何文件的所有后续访问都将显示该第二个文件。 针对性的 DoS 攻击或 Cookie 炸弹攻击（客户端发送足够多的 Cookie 来导致服务器拒绝处理该请求）可用于确保该网站显示为脱机。
为了缓解这种情况，清单只能指定与清单本身位于相同路径的 Fallback。这意味着服务器上特定目录中的内容注入上传漏洞只能升级为接管该目录及其子目录。 如果无法将文件注入到根目录，那么就无法接管整个站点。
如果某个站点遭到这种方式的攻击，则只需删除恶意的清单就可以最终解决问题，因为下次更新清单时，将会得到 404 错误，然后用户代理就会清除缓存。然而，这里的“最终”是关键词。在对用户或服务器的攻击正在进行时，从受影响的用户到受影响的站点的连接已经被阻止，用户代理将简单地假定用户处于离线状态并将继续使用恶意的清单。不幸的是，如果还使用了 Cookie 炸弹攻击，那么仅仅删除清单是不够的；此外，服务器还得配置为返回 404 或 410 响应，而不是 413 “请求实体太大”响应。
TLS 本身不会保护网站免受此攻击，因为攻击依赖于服务器本身提供的内容。 不使用应用程序缓存也不能阻止这种攻击，因为攻击依赖于攻击者提供的清单。
[SecureContext,
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
undefined update();
undefined abort();
undefined 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;
};applicationCacheReturns the ApplicationCache object that applies to the active
document of that Window.
statusReturns 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
|
interface mixin NavigatorOnLine {
readonly attribute boolean onLine;
};navigator . onLineSupport in all current engines.
Support in all current engines.
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 global changes from true to false, the user agent must
queue a global task on the networking task source given
global to fire an event named offline at global.
On the other hand, when the value that would be returned by the navigator.onLine attribute of a Window or
WorkerGlobalScope global changes from false to true, the user agent must
queue a global task on the networking task source given
global to fire an event named online at the Window or WorkerGlobalScope
object.
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>