1. 7.9 オフラインウェブアプリケーション
      1. 7.9.1 導入
        1. 7.9.1.1 レガシーアプリケーションへのオフラインキャッシュのサポート
        2. 7.9.1.2 イベントの概要
      2. 7.9.2 Application caches
      3. 7.9.3 The cache manifest syntax
        1. 7.9.3.1 サンプルマニフェスト
        2. 7.9.3.2 キャッシュマニフェストの記述
        3. 7.9.3.3 Parsing cache manifests
      4. 7.9.4 Downloading or updating an application cache
      5. 7.9.5 The application cache selection algorithm
      6. 7.9.6 Changes to the networking model
      7. 7.9.7 Expiring application caches
      8. 7.9.8 Disk space
      9. 7.9.9 Security concerns with offline applications caches
      10. 7.9.10 アプリケーションキャッシュAPI
      11. 7.9.11 ブラウザーの状態

7.9 オフラインウェブアプリケーション

Support: offline-appsChrome for Android 62+Chrome 4+UC Browser for Android 11.4+iOS Safari 3.2+Firefox 3.5+IE 10+Samsung Internet 4+Opera Mini NoneSafari 4+Edge 12+Android Browser 2.1+Opera 10.6+

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. 代わりにサービスワーカーを使用すること。[SW]

7.9.1 導入

この節は非規範的である。

ネットワーク接続が利用できない場合―たとえば、ユーザーがISPのカバレッジエリアの外に移動しているため―でも、ユーザーにウェブアプリケーションおよび文書との対話を継続できるようにするために、著者は、オフラインで作業し、オフラインで使用のためにファイルのコピーを保持するためにユーザーのブラウザーになる、ウェブアプリケーション用に必要とされるファイルの一覧を示したマニフェストを提供できる。

これを説明するために、HTMLページ"clock1.html"、CSSスタイルシート"clock.css"、およびJavaScriptスクリプト"clock.js"から成る単純な時計アプレットを考えてみる。

マニフェストを追加する前に、これらの3つのファイルは次のようになる:

<!-- clock1.html -->
<!DOCTYPE HTML>
<html>
 <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"ページを開こうとする場合、しかし、(ローカルキャッシュにまだ持つ場合を除いて)ユーザーエージェントはエラーとともに失敗する。

著者は、代わりに"clock.appcache"という、3つのファイルのマニフェストを提供できる:

CACHE MANIFEST
clock2.html
clock.css
clock.js

HTMLファイルへの小さな変化とともに、(text/cache-manifestで提供される)マニフェストがアプリケーションにリンクされている:

<!-- clock2.html -->
<!DOCTYPE HTML>
<html 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"ディレクティブ例外とともに、TLSで供給される(https:を使用して暗号化される)キャッシュページでのHTTPキャッシュヘッダーと制限は、マニフェストによって上書きされる。したがって、ページは、ユーザーエージェントがそれを更新する前にアプリケーションキャッシュから期限切れにならず、TLS経由で提供されるアプリケーションはオフラインで動作させることができる。

この例をオンラインで見る

7.9.1.1 レガシーアプリケーションへのオフラインキャッシュのサポート

この節は非規範的である。

マニフェストに記載されかつアプリケーションキャッシュに格納されたロジック(マークアップ、スクリプト、スタイルシート、画像など)とともに、アプリケーションに対する有限数の静的HTMLページとともに、およびウェブストレージまたはサーバー側にインデックス付けされたデータベースに格納されたアプリケーションおよびユーザーデーターとともに、アプリケーションロジックがアプリケーションとユーザーデータから別れる場合、アプリケーションキャッシュ機能は最も機能的に動作し、ウェブソケット、XMLHttpRequest、サーバーに送信されるイベント、または他の同様の機構を使用して動的に更新される。

このモデルはユーザーに対して高速な経験をもたらす:(おそらく古いデータを示しつつ)アプリケーション即時に読み込み、ネットワークがそれを可能にするように、新鮮なデータを高速に得られる。

しかし、レガシーアプリケーションは、サーバーから新しいHTMLページで得られた各操作とともに、ユーザーデータおよびロジックがHTMLと一緒に混合されるように設計される傾向にある。

たとえば、ニュースアプリケーションを考えてみよう。このようなアプリケーションの典型的なアーキテクチャーは、アプリケーションキャッシュ機能を使用しない場合、ユーザーはメインページをフェッチし、サーバーは現在の見出しとユーザーインタフェースロジックを一緒に混合した動的に生成されるページを返す。

しかし、アプリケーションキャッシュ機能のために設計されたニュースアプリケーションは、ロジックでのみ構成されるメインページを代わりに持つだろうし、メインページがサーバーとは別にデータをフェッチしているだろう。たとえば、XMLHttpRequestを使用して。

混合コンテンツモデルは、アプリケーションのキャッシュ機能とともにうまく動作しない:コンテンツがキャッシュされているので、常にキャッシュが更新された前回から古いデータを見て、ユーザーにもたらすだろう。

分離されたモデルと同じ速さで、従来のモデルを動作させる方法がないが、それは少なくとも好ましいオンラインアプリケーションキャッシュモードを使用してオフライン利用で使用するために改造できる。これを行うには、アプリケーションキャッシュマニフェストでオフライン作業をしたいHTMLページによって使用されるすべての静的リソースを一覧表示し、HTMLファイルからそのマニフェストを選択するmanifest属性を使用し、マニフェストの一番下に次の行を追加する:

SETTINGS:
prefer-online
NETWORK:
*

ユーザーがオフラインである際に、許可するすべてのリソースが通常アクセスされるマニフェストに記載されていない一方で、これは、マスターエントリにのみ使用されるアプリケーションキャッシュを引き起こし、(本質的にマニフェストに記載されているリソースをピン留めする)分割不能なHTTPキャッシュとして使用されるアプリケーションキャッシュを引き起こす。

7.9.1.2 イベントの概要

この節は非規範的である。

ユーザーがマニフェストを宣言するページを訪問する際に、ブラウザーはキャッシュを更新しようとする。これは、ユーザーエージェントが最後にそれを見てからマニフェストが変更された場合、それが言及されているすべてのリソースを再ダウンロードして改めてキャッシュし、マニフェストのコピーを取得することによってこれを行う。

これが起こっているように、ユーザーに適切な方法で通知できるように、イベントの数は、キャッシュの更新の状態へと更新されたスクリプトを保つためにApplicationCacheオブジェクトで発火する。イベントは次のとおり:

イベント名 インターフェイス 発火条件 次のイベント
checking Event ユーザーエージェントは、更新をチェックする、または初回のマニフェストをダウンロードしようとしている。これは、常にシーケンスの最初のイベントである。 noupdatedownloadingobsoleteerror
noupdate Event マニフェストは変更されなかった。 シーケンス内の最後のイベント。
downloading Event ユーザーエージェントは更新を発見し、それをフェッチしている、または初回のマニフェストで記載されたリソースをダウンロードしている。 progresserrorcachedupdateready
progress ProgressEvent ユーザーエージェントは、マニフェストで記載されたリソースをダウンロードしている。イベントオブジェクトのtotal属性は、ダウンロードされたファイルの合計数を返す。イベントオブジェクトのloaded属性は、これまでに処理されたファイルの数を返す。 progresserrorcachedupdateready
cached Event マニフェストに記載されたリソースがダウンロードされ、アプリケーションがキャッシュされた。 シーケンス内の最後のイベント。
updateready Event マニフェストに記載されたリソースは新しく再ダウンロードされており、スクリプトは新しいキャッシュに切り替えるためにswapCache()を使用できる。 シーケンス内の最後のイベント。
obsolete Event マニフェストは404または410ページになっていることが判明し、アプリケーションのキャッシュを削除している。 シーケンス内の最後のイベント。
error Event マニフェストが404または410ページだったので、アプリケーションをキャッシュする試みが中止された。 シーケンス内の最後のイベント。
マニフェストは変更されなかったが、マニフェストを参照するページが正しくダウンロードでなかった。
マニフェストに記載されたリソースを取得するときに致命的なエラーが発生した。
更新されている間にマニフェストが変更された。 ユーザーエージェントは、再び一時的にファイルを取得しようする。

これらのイベントはキャンセル可能である。それらのデフォルトアクションは、ダウンロードの進捗情報を表示するためのユーザーエージェントに対するものである。ページが独自のアップデートのUIが表示する場合、イベントのキャンセルは、冗長な進捗情報の表示からユーザーエージェントを防ぐだろう。

7.9.2 Application caches

An application cache is a set of cached resources consisting of:

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.

7.9.3 The cache manifest syntax

7.9.3.1 サンプルマニフェスト

この節は非規範的である。

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

同様に次のように記述することができる:

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であることを指定し、他のサイト上のリソースにアクセスがブロックされないことを意味する。(汎用フォールバック名前空間なので、同じサイト上のリソースがすでにブロックされない。)

このマニフェスト上のすべてのページのように、同じページにヒットする後続はキャッシュからすぐに読み込まれるので、それらが取得されるようにローカルでキャッシュされるだろう。マニフェストが変更されるまで、これらのページは、再度サーバーから取得されることはない。マニフェストが変更される際、次にすべてのファイルが再ダウンロードされる。

スタイルシートや画像などのようなサブリソースは、しかし、通常のHTTPキャッシングセマンティックスを使用してのみキャッシュされる。

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
7.9.3.2 キャッシュマニフェストの記述

マニフェストは、text/cache-manifestMIMEタイプを使用して配信しなければならない。text/cache-manifestMIMEタイプを使用して配信されるすべてのリソースは、この節で説明するように、アプリケーションキャッシュマニフェストの構文に従わなければならない。

アプリケーションキャッシュマニフェストは、テキストがUTF-8を使用してエンコードされるテキストファイルである。アプリケーションキャッシュマニフェストでのデータは行ベースである。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]

これは、すべてのtext/*型が唯一のCRLF改行を許可する必要がある、RFC 2046の故意の違反である。しかし、この要件は時代遅れである。CR、LFおよびCRLFの改行の使用は一般的に支持されており、実際に時にCRLFはテキストエディターでサポートされない[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. 他のテキストが最初の行にある場合、無視される。

後続の行がもしあれば、すべて次のいずれかでなければならない:

空白行

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.

セクションヘッダー

セクションヘッダーは、現在のセクションを変更する。可能な4つのセクションヘッダーが存在する:

CACHE:
明示的なセクションに切り替える。
FALLBACK:
代替セクションに切り替える。
NETWORK:
Switches to the online safelist section.
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.

皮肉なことに、デフォルトでは、現在のセクションは、明示的なセクションである。

現在のセクションのデータ

データ行が取得しなければならない形式は、現在のセクションに依存する。

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.

現在のところ1つの設定のみが定義される:

キャッシュモード設定
これは、文字列"prefer-online"で構成される。この文字列は、キャッシュモード優先オンラインに設定する。(キャッシュモードはデフォルトで高速になる。)

設定セクション内で、各設定は1回以上出現してはならない。

マニフェストは、複数回のセクションを含んでもよい。セクションは空であってもよい。

フォールバック名前空間自体に関連付けられたフォールバックページであるURL、およびそれらの名前空間は、データ行の最初のURLである名前空間、および2番目のURLであるフォールバックページ対応する、フォールバックセクションで指定されなければならない。キャッシュされる他のすべてのページは、明示的なセクションに記載されなければならない。

フォールバック名前空間およびフォールバックエントリは、マニフェスト自身と同じ生成元を持たなければならない。Fallback namespaces must also be in the same path as the manifest's URL.

フォールバック名前空間は、複数回記載されてはならない。

ユーザーエージェントがオンラインセーフリストに入れる名前空間は、すべてオンラインセーフリストセクションで指定されなければならない。(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.

相対URLはマニフェスト自身のURLを基準に指定されなければならない。マニフェスト内のすべてのURLは、(明示的または暗黙的に、相対URLを使用して)マニフェスト自身と同じschemeを持たなければならない。[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.

7.9.3.3 Parsing cache manifests

When a user agent is to parse a manifest, it means that the user agent must run the following steps:

  1. UTF-8 decode the byte stream corresponding with the manifest to be parsed.

    The UTF-8 decode algorithm strips a leading BOM, if any.

  2. Let base URL be the absolute URL representing the manifest.

  3. Apply the URL parser to base URL, and let manifest path be the path component thus obtained.

  4. 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.)

  5. 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.

  6. Let explicit URLs be an initially empty list of absolute URLs for explicit entries.

  7. Let fallback URLs be an initially empty mapping of fallback namespaces to absolute URLs for fallback entries.

  8. Let online safelist namespaces be an initially empty list of absolute URLs for an online safelist.

  9. Let online safelist wildcard flag be blocking.

  10. Let cache mode flag be fast.

  11. Let input be the decoded text of the manifest's byte stream.

  12. Let position be a pointer into input, initially pointing at the first character.

  13. If the characters starting from position are "CACHE", followed by a U+0020 SPACE character, followed by "MANIFEST", then advance position to the next character after those. Otherwise, this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.

  14. 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; abort this algorithm with a failure while checking for the magic signature.

  15. This is a cache manifest. The algorithm cannot fail beyond this point (though bogus lines can get ignored).

  16. 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.)

  17. Let mode be "explicit".

  18. 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.

  19. 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.

  20. Drop any trailing U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters at the end of line.

  21. If line is the empty string, then jump back to the step labeled start of line.

  22. If the first character in line is a U+0023 NUMBER SIGN character (#), then jump back to the step labeled start of line.

  23. 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.

  24. 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.

  25. 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.

  26. 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.

  27. If line ends with a U+003A COLON character (:), then set mode to "unknown" and jump back to the step labeled start of line.

  28. This is either a data line or it is syntactically incorrect.

  29. Let position be a pointer into line, initially pointing at the start of the string.

  30. Let tokens be a list of strings, initially empty.

  31. While position doesn't point past the end of line:

    1. Let current token be an empty string.

    2. 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.

    3. Add current token to the tokens list.

    4. 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.

  32. Process tokens as follows:

    If mode is "explicit"

    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.

    If mode is "fallback"

    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 mode is "online safelist"

    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 mode is "settings"

    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.

    If mode is "unknown"

    Do nothing. The line is ignored.

  33. 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.)

  34. 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.

7.9.4 Downloading or updating an application cache

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:

  1. 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).

  2. Atomically, so as to avoid race conditions, perform the following substeps:

    1. Pick the appropriate substeps:

      If these steps were invoked with an absolute URL purported to identify a manifest

      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.

      If these steps were invoked with an application cache group

      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.

    2. Let cache group be the application cache group identified by manifest URL.

    3. 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.

    4. 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:

      1. 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.

      2. 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.

    5. 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:

      1. 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.

      2. 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.

    6. 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.

    7. Set the status of cache group to checking.

    8. For each cache host associated with an application cache in cache group, queue a post-load task run these steps:

      1. 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.

      2. 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.

  3. If this is a cache attempt, then this algorithm was invoked with a cache host; queue a post-load task to run these steps:

    1. 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.

    2. 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.

  4. 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.

  5. 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).

  6. If fetching the manifest fails due to a 404 or 410 response status, then run these substeps:

    1. 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.

    2. Let task list be an empty list of tasks.

    3. 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:

      1. 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.

      2. 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.

    4. 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:

      1. 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.

      2. 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.

    5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  7. 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]

  8. 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:

    1. Let cache be the newest application cache in cache group.

    2. Let task list be an empty list of tasks.

    3. 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:

      1. 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.

      2. 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).

    4. 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:

      1. 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.

      2. 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.

    5. Empty cache group's list of pending master entries.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  9. Let new cache be a newly created application cache in cache group. Set its completeness flag to incomplete.

  10. For each entry in cache group's list of pending master entries, associate the Document for this entry with new cache.

  11. Set the status of cache group to downloading.

  12. For each cache host associated with an application cache in cache group, queue a post-load task to run these steps:

    1. 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.

    2. 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.

  13. Let file list be an empty list of URLs with flags.

  14. Add all the URLs in the list of explicit entries obtained by parsing manifest to file list, each flagged with "explicit entry".

  15. Add all the URLs in the list of fallback entries obtained by parsing manifest to file list, each flagged with "fallback entry".

  16. 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".

  17. 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.

  18. 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.

    1. 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.

    2. For each cache host associated with an application cache in cache group, queue a progress post-load task to run these steps:

      1. 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]

      2. 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.

    3. 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".

    4. 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.

    5. 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 the URL being processed was flagged as an "explicit entry" or a "fallback entry"

      If these steps are being run in parallel for any other URLs in file list, then abort these steps for those other URLs. Run the cache failure steps.

      Redirects are fatal because they are either indicative of a network problem (e.g. a captive portal); or would allow resources to be added to the cache under URLs that differ from any URL that the networking model will allow access to, leaving orphan entries; or would allow resources to be stored under URLs different than their true URLs. All of these situations are bad.

      If the error was a 404 or 410 HTTP response
      If the resource was labeled with the "no-store" cache directive

      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.

    6. 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.

    7. If the URL being processed was flagged as an "explicit entry" in file list, then categorize the entry as an explicit entry.

    8. If the URL being processed was flagged as a "fallback entry" in file list, then categorize the entry as a fallback entry.

    9. If the URL being processed was flagged as an "master entry" in file list, then categorize the entry as a master entry.

    10. 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.

  19. For each cache host associated with an application cache in cache group, queue a progress post-load task to run these steps:

    1. 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]

    2. 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.

  20. Store the list of fallback namespaces, and the URLs of the fallback entries that they map to, in new cache.

  21. Store the URLs that form the new online safelist in new cache.

  22. Store the value of the new online safelist wildcard flag in new cache.

  23. Store the value of the new cache mode flag in new cache.

  24. 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:

    1. Unassociate the Document for this entry from new cache.

    2. Queue a post-load task to run these steps:

      1. 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.

      2. 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.

    3. 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:

      1. Discard cache group and its only application cache, new cache.

      2. If appropriate, remove any user interface indicating that an update for this cache is in progress.

      3. Abort the application cache download process.

    4. 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.

  25. 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.

  26. 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.

  27. 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.

  28. Otherwise, store manifest in new cache, if it's not there already, and categorize its entry as the manifest.

  29. Set the completeness flag of new cache to complete.

  30. Let task list be an empty list of tasks.

  31. 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:

    1. 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.

    2. 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:

    1. 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.

    2. 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.

  32. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  33. Set the update status of cache group to idle.

  34. For each task in task list, queue that task as a post-load task.

The cache failure steps are as follows:

  1. Let task list be an empty list of tasks.

  2. 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.

    1. Wait for the resource for this entry to have either completely downloaded or failed.

    2. Unassociate the Document for this entry from its application cache, if it has one.

    3. Create a task to run these steps and append it to task list:

      1. 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.

      2. 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.

  3. 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:

    1. 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.

    2. 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.

  4. Empty cache group's list of pending master entries.

  5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

  6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  7. Let the status of cache group be idle.

  8. If this was a cache attempt, discard cache group altogether.

  9. For each task in task list, queue that task as a post-load task.

  10. 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:

If target's node document is ready for post-load tasks

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:

  1. 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.

  2. Label task as a progress task.

  3. Queue a post-load task task.

The task source for these tasks is the networking task source.

7.9.5 The application cache selection algorithm

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:

If there is a manifest URL, and document was loaded from an application cache, and the URL of the manifest of that cache's application cache group is not the same as manifest URL

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.

If document was loaded from an application cache, and that application cache still exists (it is not now obsolete)

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.

If document was loaded using `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.

7.9.6 Changes to the networking model

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. If the application cache's online safelist wildcard flag is open, then fetch the resource normally and return.

  6. 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.

7.9.7 Expiring application caches

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.

7.9.8 Disk space

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.

7.9.9 Security concerns with offline applications caches

この節は非規範的である。

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.

7.9.10 アプリケーションキャッシュAPI

[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;
};
cache = window . applicationCache

Returns the ApplicationCache object that applies to the active document of that Window.

cache . status

以下に定義された定数で与えられるように、アプリケーションキャッシュの現在のステータスを返す。

cache . update()

アプリケーションキャッシュのダウンロードプロセスを起動する。

Throws an "InvalidStateError" DOMException if there is no application cache to update.

ユーザーエージェントは通常、自動的にアプリケーションキャッシュを更新する処理をするので、通常このメソッドを呼び出す必要はない。

このメソッドは、長期のアプリケーションのような状況で役立つ。たとえば、ウェブメールアプリケーションは一度に何週間もブラウザータブで開いたままかもしれない。このようなアプリケーションは、毎日更新をテストできるだろう。

cache . abort()

アプリケーションキャッシュのダウンロード処理を中止する。

このメソッドは、(帯域幅が限られるためなどで)ユーザーが更新を停止したい場合に、独自のキャッシング進捗UIを表示するウェブアプリケーションで使用されることを意図する。

cache . swapCache()

新しいものが存在する場合、最新のアプリケーションキャッシュに切り替わる。If there isn't, throws an "InvalidStateError" DOMException.

これは、以前にロードされたリソースが再読み込みされることはない。たとえば、画像が急にリロードされないと、スタイルシートやスクリプトが再解析または再評価されない。唯一の変更点は、キャッシュされたリソースに対する後続の要求が新しいコピーを取得することである。

このメソッドが呼び出される前にupdatereadyイベントが発火する。一度発火すると、ウェブアプリケーションは、その余暇で、より最近のアップデートで一つに基礎となるキャッシュを切り替えるためにこのメソッドを呼び出す。これを適切に使うためには、アプリケーションは動作に新しい機能をもたらすことができるようにする必要がある。たとえば、新しい機能を有効にするためにスクリプトをリロードするなど。

swapCache()の代替は、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(数値0)

ApplicationCacheオブジェクトのキャッシュホストは、この時点でアプリケーションキャッシュに関連付けられていない。

IDLE(数値1)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスidleであるアプリケーションキャッシュに関連付けられ、そのアプリケーションキャッシュは、そのアプリケーションキャッシュグループ最新のキャッシュであり、アプリケーションキャッシュグループは、obsoleteとマークされない。

CHECKING(数値2)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスcheckingであるアプリケーションキャッシュに関連付けられる。

DOWNLOADING(数値3)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスdownloadingであるアプリケーションキャッシュに関連付けられる。

UPDATEREADY(数値4)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ更新ステータスidleであるアプリケーションキャッシュに関連付けられ、そのアプリケーションキャッシュグループobsoleteとしてマークされないが、そのアプリケーションキャッシュは、そのグループ内の最新のキャッシュではない

OBSOLETE(数値5)

ApplicationCacheオブジェクトのキャッシュホストは、アプリケーションキャッシュグループ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:

  1. Check that ApplicationCache object's cache host is associated with an application cache. If it is not, then throw an "InvalidStateError" DOMException and abort these steps.

  2. 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.)

  3. 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.)

  4. 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.

  5. Let new cache be the newest application cache in the same application cache group as cache whose completeness flag is complete.

  6. 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:

イベントハンドラー イベントハンドラーイベント型
onchecking checking
onerror error
onnoupdate noupdate
ondownloading downloading
onprogress progress
onupdateready updateready
oncached cached
onobsolete obsolete

Support: online-statusChrome for Android 62+Chrome 14+UC Browser for Android (limited) 11.4+iOS Safari 4.2+Firefox 41+IE 9+Samsung Internet 4+Opera Mini NoneSafari 5+Edge 12+Android Browser 2.3+Opera 15+

Source: caniuse.com

[NoInterfaceObject, Exposed=(Window,Worker)]
interface NavigatorOnLine {
  readonly attribute boolean onLine;
};
self . navigator . onLine

ユーザーエージェントが正確にオフラインである(ネットワークから切断されている)場合にfalseを返すユーザーエージェントがオンラインかもしれない場合にtrueを返す。

この属性値が変更される場合、イベントonlineおよびofflineが発火する。

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.

この属性は、本質的に信頼できない。コンピューターは、インターネット接続がなくてもネットワークに接続できる。

この例において、ブラウザーがオンラインおよびオフラインになるように、インジケーターが更新される。

<!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>