차례
    1. 5.6 오프라인 웹 어플리케이션
      1. 5.6.1 소개
        1. 5.6.1.1 이벤트 요약
      2. 5.6.2 어플리케이션 캐쉬
      3. 5.6.3 캐쉬 매니페스트 문법
        1. 5.6.3.1 매니페스트 샘플
        2. 5.6.3.2 캐쉬 매니페스트 작성
        3. 5.6.3.3 캐쉬 매니페스트 처리
      4. 5.6.4 어플리케이션 캐쉬의 다운로드 또는 업데이트
      5. 5.6.5 어플리케이션 캐쉬 선택 알고리즘
      6. 5.6.6 네트워크 모델의 변경
      7. 5.6.7 어플리케이션 캐쉬 만료
      8. 5.6.8 디스크 용량
      9. 5.6.9 어플리케이션 캐쉬 API
      10. 5.6.10 브라우저 상태

5.6 오프라인 웹 어플리케이션

5.6.1 소개

This section is non-normative.

사용자가 네트워크 연결을 사용할 수 없는 경우 - 예를 들어, 인터넷 서비스 제공자가 커버할 수 없는 영역으로 이동하는 경우 - 에도 계속해서 웹 어플리케이션과 문서들을 이용할 수 있도록 하기 위해, 웹 어플리케이션이 오프라인으로 동작하는데 필요한 파일들의 목록을 저장하고, 사용자의 브라우저가 그러한 파일들의 카피를 보관하도록 하는 매니페스트manifest를 제공할 수 있습니다.

In order to enable users to continue interacting with Web applications and documents even when their network connection is unavailable — for instance, because they are traveling outside of their ISP's coverage area — authors can provide a manifest which lists the files that are needed for the Web application to work offline and which causes the user's browser to keep a copy of the files for use offline.

이러한 것을 묘사하기 위해, 간단한 HTML 페이지를 가정해 봅니다. clock.html, clock.css, clock.js 로 이루어집니다.

To illustrate this, consider a simple clock applet consisting of an HTML page "clock.html", a CSS style sheet "clock.css", and a JavaScript script "clock.js".

매니페스트를 추가하기 전에는, 위 세개의 파일은 이러한 형태였을 것입니다:

Before adding the manifest, these three files might look like this:

<!-- clock.html -->
<!DOCTYPE HTML>
<html>
 <head>
  <title>Clock</title>
  <script src="clock.js"></script>
  <link rel="stylesheet" href="clock.css">
 </head>
 <body>
  <p>The time is: <output id="clock"></output></p>
 </body>
</html>
/* clock.css */
output { font: 2em sans-serif; }
/* clock.js */
setTimeout(function () {
    document.getElementById('clock').value = new Date();
}, 1000);

사용자가 clok.html 을 오프라인에서 열려고 하면, 사용자 에이전트는(로컬 캐쉬에 이것을 가지고 있지 않다면) 에러를 낼 것입니다.

If the user tries to open the "clock.html" page while offline, though, the user agent (unless it happens to have it still in the local cache) will fail with an error.

그대신 이 세개의 파일에 대한 매니페스트를 제공할 수 있습니다:

The author can instead provide a manifest of the three files:

CACHE MANIFEST
clock.html
clock.css
clock.js

HTML 파일에 약간의 변경을 함으로서, 매니페스트(text/cache-manifest)가 어플리케이션에 링크됩니다:

With a small change to the HTML file, the manifest (served as text/cache-manifest) is linked to the application:

<!-- clock.html -->
<!DOCTYPE HTML>
<html manifest="clock.manifest">
 <head>
  <title>Clock</title>
  <script src="clock.js"></script>
  <link rel="stylesheet" href="clock.css">
 </head>
 <body>
  <p>The time is: <output id="clock"></output></p>
 </body>
</html>

이제, 사용자가 그 페이지로 이동하면 브라우저는 파일들을 캐쉬하며 사용자가 오프라인인 경우에도 이용할 수 있도록 만듭니다.

Now, if the user goes to the page, the browser will cache the files and make them available even when the user is offline.

메인 페이지도 매니페스트에 포함시키기를 권장합니다만, 현실적으로 그러한 매니페스트를 참조하는 페이지는, 그것이 명시적으로 언급되지 않았다고 하더라도 자동적으로 캐쉬됩니다.

Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly mentioned.

TLS(https: 를 사용하여 암호화됩니다)를 통해 제공된 페이지들의 헤더와 제한들에 대한 HTTP 캐쉬는 매니페스트에 의해 덮어써집니다. 따라서, 페이지들은 사용자 에이전트가 그것을 업데이트하기 전에는 어플리케이션 캐쉬에서 기간 만료가 일어나지 않을 것이며, TLS를 통해 제공된 어플리케이션 역시 오프라인으로 사용할 수 있습니다.

HTTP cache headers and restrictions on caching pages served over TLS (encrypted, using https:) are overridden by manifests. Thus, pages will not expire from an application cache before the user agent has updated it, and even applications served over TLS can be made to work offline.

5.6.1.1 이벤트 요약

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.

이러한 것이 진행됨에 따라, 캐쉬의 업데이트된 상태가 스크립트에도 반영되도록, 다수의 이벤트들이 ApplicationCache 객체에 발생하며, 사용자가 적절한 알림을 받을 수 있습니다. 그러한 이벤트들은 다음과 같습니다:

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

이벤트가 발생하는 경우

Dispatched when...

다음 이벤트

Next events

checking Event

사용자 에이전트가 업데이트를 체크하고 있거나, 매니페스트를 처음으로 다운로드 하려고 시도하는 중입니다.이것은 항상 처음 이벤트입니다.

The user agent is checking for an update, or attempting to download the manifest for the first time. This is always the first event in the sequence.

noupdate, downloading, obsolete, error
noupdate Event

매니페스트가 변경되지 않았습니다.

The manifest hadn't changed.

이벤트의 연속 중 마지막 것

Last event in sequence.

downloading Event

사용자 에이전트가 변경된 점을 발견하였고 그것을 받아오는 중이거나, 매니페스트에 목록화된 자원들을 처음으로 받아 오는 중입니다.

The user agent has found an update and is fetching it, or is downloading the resources listed by the manifest for the first time.

progress, error, cached, updateready
progress ProgressEvent

사용자 에이전트가 매니페스트에 나열된 자원들을 다운로드하는 중입니다.

The user agent is downloading resources listed by the manifest.

progress, error, cached, updateready
cached Event

매니페스트에 나열된 자원들을 다운로드하였으며, 어플리케이션이 이제 캐쉬되었습니다.

The resources listed in the manifest have been downloaded, and the application is now cached.

이벤트의 연속 중 마지막 것

Last event in sequence.

updateready Event

매니페스트에 나열된 자원들이 새롭게 다운로드되었으며, 스크립트는 새로운 캐쉬로 변경하도록 swapCache() 를 사용할 수 있습니다.

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

매니페스트가 404, 또는 410 페이지를 발견하였으므로 어플리케이션 캐쉬가 삭제되는 중입니다.

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

매니페스트가 404, 또는 410페이지였으므로, 어플리케이션을 캐쉬하려는 시도가 취소되었습니다.

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.

5.6.2 어플리케이션 캐쉬

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 or a SharedWorkerGlobalScope object. A cache host can be associated with an application cache. [WEBWORKERS]

A Document initially is not associated with an application cache, but can become associated with one early during the page load process, when steps in the parser and in the navigation sections cause cache selection to occur.

A SharedWorkerGlobalScope can be associated with an application cache when it is created. [WEBWORKERS]

Each cache host has an associated ApplicationCache object.


Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following:


A URL matches a fallback namespace if there exists a relevant application cache whose manifest's URL has the same origin as the URL in question, and that has a fallback namespace that is a prefix match for the URL being examined. If multiple fallback namespaces match the same URL, the longest one is the one that matches. A URL looking for a fallback namespace can match more than one application cache at a time, but only matches one namespace in each cache.

If a manifest http://example.com/app1/manifest declares that http://example.com/resources/images is a fallback namespace, and the user navigates to HTTP://EXAMPLE.COM:80/resources/images/cat.png, then the user agent will decide that the application cache identified by http://example.com/app1/manifest contains a namespace with a match for that URL.

5.6.3 캐쉬 매니페스트 문법

5.6.3.1 매니페스트 샘플

This section is non-normative.

이 매니페스트 예제는 2개의 이미지와 1개의 스타일시트를 캐쉬할것을 요청하며, CGI 스크립트를 하나 지정합니다.

This example manifest requires two images and a style sheet to be cached and whitelists a CGI script.

CACHE MANIFEST
# 위 줄은 필요한 것입니다.
# the above line is required
 
# 이것은 주석입니다. 
# this is a comment
# 파일의 어디에든, 필요한만큼의 주석을 달 수 있습니다.
# there can be as many of these anywhere in the file
# 주석은 전부 무시됩니다.
# they are all ignored
  # 주석들 사이에 공백을 사용할 수 있습니다.
  # comments can have spaces before them
  # 하지만 모두 한 줄에 있어야 합니다.
  # but must be alone on the line
 
# 빈 줄 역시 무시됩니다. 
# blank lines are ignored too
 
# 이것들은 캐쉬되어야 할 파일들입니다. 
# 캐쉬될 파일들을 처음에 나열할수도 있고, 
# 만약 처음에 나열하지 않는다면 
# "CACHE:" 헤더를 목록의 앞에 첨부하면 됩니다.
# 그렇게 한 예가 아래에 있습니다. 
# 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
 
# 이것은 온라인인 파일의 목록입니다. 이것은 캐쉬되지 않으며,
# 이 파일에 대한 참조 역시 캐쉬되지 않고 항상 네트워크를 경유합니다
# (또는, 사용자가 오프라인인 경우, 그런 시도를 합니다).
# (역주 : NETWORK: 헤더를 눈여겨 보십시오) 
# here is a file for the online whitelist -- it isn't cached, and
# references to this file will bypass the cache, always hitting the
# network (or trying to, if the user is offline).
NETWORK:
comm.cgi
 
# 캐쉬되어야 할 다른 파일들입니다. 여기에서는 CSS 하나입니다. 
# here is another set of files to cache, this time just the CSS file.
CACHE:
style/default.css

위의 예제는 아래의 것과 동일합니다:

It could equally well be written as follows:

CACHE MANIFEST
NETWORK:
comm.cgi
CACHE:
style/default.css
images/sound-icon.png
images/background.png

오프라인 어플리케이션 캐쉬 매니페스트는 절대경로와 상대경로를 모두 사용할 수 있습니다:

Offline application cache manifests can use absolute paths or even absolute URLs:

CACHE MANIFEST
 
/main/home
/main/app.js
/settings/home
/settings/app.js
http://img.example.com/logo.png
http://img.example.com/check.png
http://img.example.com/cross.png

다음의 매니페스트는 사용자가 오프라인인 경우, 사이트의 모든 페이지들에 대해 표시될 모든 에러들을 하나의 페이지로 모을 것을 정의합니다. 이것은 또한 온라인 화이트리스트 와일드카드 플랙이 open 상태임을 명시하는데, 다른 사이트에 있는 자원들에 대한 접근은 블럭되지 않을 것이라는 의미입니다. (동일한 사이트의 자원들은 캐치-올 폴백 네임스페이스를 통해 이미 블럭이 해제되어 있습니다)

The following manifest defines a catch-all error page that is displayed for any page on the site while the user is offline. It also specifies that the online whitelist wildcard flag is open, meaning that accesses to resources on other sites will not be blocked. (Resources on the same site are already not blocked because of the catch-all fallback namespace.)

사이트의 모든 페이지들이 이 매니페스트를 참조하는 한, 페이지들은 다운로드되면서 로컬에 캐쉬될 것이고, 따라서 그 후 동일한 페이지를 방문하면 페이지를 캐쉬에서 즉시 불러올 것입니다. 매니페스트가 변경되기 전에는, 그러한 페이지들은 서버에서 다시 다운로드되지 않을 것입니다. 매니페스트가 변경되면, 모든 파일들이 다시 다운로드되어질 것입니다.

So long as all pages on the site reference this manifest, they will get cached locally as they are fetched, so that subsequent hits to the same page will load the page immediately from the cache. Until the manifest is changed, those pages will not be fetched from the server again. When the manifest changes, then all the files will be redownloaded.

스타일시트, 이미지, 기타 부속자원들은 일반적인 HTTP 캐슁 방법을 통해 캐쉬되어질 것입니다.

Subresources, such as style sheets, images, etc, would only be cached using the regular HTTP caching semantics, however.

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
5.6.3.2 캐쉬 매니페스트 작성

매니페스트는 반드시 마임타입 text/cache-manifest를 통해 제공되어야 합니다. 그러한 마임 타입으로 제공된 모든 자원들은 어플리케이션 캐쉬 매니페스트의 문법을 따라야 하며, 그 문법은 이 섹션에서 설명되어 있습니다.

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.

어플리케이션 캐쉬 매니페스트는 텍스트 파일이고, 그 텍스트는 UTF-8로 인코드됩니다. 매니페스트의 데이터는 행 기반입니다. 새로운 줄은 반드시 U+000A(LF) - U+000D(CR), 또는 U+000D(CR) - U+000A(LF)쌍으로 나타내어져야 합니다.

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

이것은 RFC 2046의 두가지 항목에 대한 의도된 위반입니다. RFC 2046은 모든 text/* 타입이 open-ended 문자 인코딩을 지원할 것과, 또한 줄바꿈 문자로 CRLF 문자만을 허용할 것을 요구합니다. 하지만, 이러한 요구사항은 오래된 것입니다; 이제는 UTF-8이 널리 사용되며, 다른 인코딩을 지원할 필요는 더이상 없습니다. 또한 CR, LF, CRLF로 줄바꿈하는 것이 일반적으로 지원되며, CRLF를 지원하지 않는 텍스트 에디터들도 있습니다.

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]

매니페스트의 첫 줄은 반드시 "CACHE" 문자열, 하나의 space 문자, "MANIFEST" 문자열, 그리고 하나의 space 문자 또는 하나의 tab 문자, 그리고 하나의 CR 또는 LF 문자로 구성되어야 합니다. 첫 줄의 맨 처음에 선택적으로 U+FEFF BOM 문자가 올 수 있습니다. 첫 줄에 다른 텍스트가 있을 경우, 그것은 무시됩니다.

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:

빈 줄 A blank line

빈 줄은 0개 혹은 그 이상의 space 문자와 tab 문자만을 포함할 수 있습니다.

Blank lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters only.

주석 A comment

주석 행은 반드시 (0 혹은 그 이상의 space 또는 tab) - (#) - (0 혹은 그 이상의 space 또는 tab) - (줄바꿈문자를 제외한 문자들)의 형태를 가져야 합니다.

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.

주석은 한 줄로 써야 합니다. 주석에 URL을 포함해야 한다면, "#"문자는 조각 식별자의 일부분인 것으로 잘못 인식될 것입니다.

Comments must be on a line on their own. If they were to be included on a line with a URL, the "#" would be mistaken for part of a fragment identifier.

섹션 헤더 A section header

섹션 헤더는 현재 섹션을 변경합니다. 3가지를 사용할 수 있습니다.

Section headers change the current section. There are three possible section headers:

CACHE:

캐쉬 섹션explicit section으로 변경합니다.

Switches to the explicit section.

FALLBACK:

폴백 섹션으로 변경합니다.

Switches to the fallback section.

NETWORK:

온라인 화이트리스트 섹션

Switches to the online whitelist section.

섹션 헤더는 반드시 (0 혹은 그 이상의 space 또는 tab) - (위 3가지 중 하나) - (:) - (0 혹은 그 이상의 space 또는 tab) 의 형태를 가져야 합니다.

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.

섹션 데이터 Data for the current section

데이터 행이 반드시 따라야 할 형식은 섹션에 따라 다릅니다. 1)

The format that data lines must take depends on the current section.

캐쉬 섹션 : (공백) - (URL) - (공백)

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 identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

폴백 섹션 : (공백) - (URL) - (공백) - (URL) - (공백)

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 identifying a resource other than the manifest itself, one or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, another valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

온라인 화이트리스트 섹션 : (공백) - (* 문자, 또는 URL) - (공백)

When the current section is the online whitelist 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 identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

매니페스트는 섹션들을 한번 이상 포함할 수 있습니다. 섹션은 비어 있을 수 있습니다.

Manifests may contain sections more than once. Sections may be empty.

매니페스트의 <스키마>https: 이거나 기타 암호화된 데이터 전송을 위해 의도된 스키마라면, 캐쉬 섹션의 모든 URL은 매니페스트와 같은 근원이어야 합니다.

If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself.

폴백 네임스페이스와 연결될 URL들, 그리고 그 네임스페이스는 폴백 섹션에 주어져야 합니다. 네임스페이스는 데이터 행의 첫번째 URL 이며, 그에 대응하는 폴백 페이지는 두번째 URL입니다. 캐쉬되어야 할 다른 모든 페이지들은 반드시 캐쉬 섹션에 나열되어야 합니다.

URLs that are to be fallback pages associated with fallback namespaces, and those namespaces themselves, must be given in fallback sections, with the namespace being the first URL of the data line, and the corresponding fallback page being the second URL. All the other pages to be cached must be listed in explicit sections.

폴백 네임스페이스와 폴백 항목은 매니페스트와 같은 근원이어야 합니다.

Fallback namespaces and fallback entries must have the same origin as the manifest itself.

폴백 네임스페이스는 한번만 사용되어야 합니다.

A fallback namespace must not be listed more than once.

사용자 에이전트가 온라인 화이트리스트에 넣을 네임스페이스들은 모두 네트워크 섹션에서 명시되어야 합니다. (서버와 통신하기 위해 사용할 것으로 의도된 모든 URL에서 이러한 것이 필요합니다) 모든 URL이 이러한 방식으로 자동적으로 화이트리스트에 포함될 것을 명시하려면, * 문자를 URL 중 하나인 것으로 명시할 수 있습니다.

Namespaces that the user agent is to put into the online whitelist must all be specified in online whitelist sections. (This is needed for any URL that the page is intending to use to communicate back to the server.) To specify that all URLs are automatically whitelisted in this way, a U+002A ASTERISK character (*) may be specified as one of the URLs.

온라인 화이트리스트에 포함된 네임스페이스가, 역시 온라인 화이트리스트에 포함된 다른 네임스페이스와 프리픽스 매치를 이룬다면, 이러한 것을 온라인 화이트리스트에 포함시켜서는 안됩니다.

Authors should not include namespaces in the online whitelist for which another namespace in the online whitelist is a prefix match.

상대 URL은 매니페스트의 URL에 기준하여야 합니다. 매니페스트에 있는 모든 URL은 반드시 매니페스트와 같은 <스키마>(명시적이든, 그렇지 않든)를 가져야 합니다.

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은 조각 식별자를 가질 수 없습니다. (즉, 매니페스트의 URL에는 # 문자가 허용되지 않습니다.)

URLs in manifests must not have fragment identifiers (i.e. the U+0023 NUMBER SIGN character isn't allowed in URLs in manifests).

폴백 네임스페이스와 온라인 화이트리스트의 네임스페이스는 프리픽스 매치입니다.

Fallback namespaces and namespaces in the online whitelist are matched by prefix match.

5.6.3.3 캐쉬 매니페스트 처리

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

  1. The user agent must decode the byte stream corresponding with the manifest to be parsed as UTF-8, with error handling.

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

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

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

  5. Let online whitelist namespaces be an initially empty list of absolute URLs for an online whitelist.

  6. Let online whitelist wildcard flag be blocking.

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

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

  9. If position is pointing at a U+FEFF BYTE ORDER MARK (BOM) character, then advance position to the next character.

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

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

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

  13. Collect a sequence of characters that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters, and ignore those characters. (Extra text on the first line, after the signature, is ignored.)

  14. Let mode be "explicit".

  15. Start of line: If position is past the end of input, then jump to the last step. Otherwise, collect a sequence of characters that are U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), U+0020 SPACE, or U+0009 CHARACTER TABULATION (tab) characters.

  16. Now, collect a sequence of characters that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters, and let the result be line.

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

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

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

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

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

  22. If line equals "NETWORK:" (the word "NETWORK" followed by a U+003A COLON character (:)), then set mode to "online whitelist" and jump back to the step labeled "start of line".

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

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

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

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

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

  28. Process tokens as follows:

    If mode is "explicit"

    Resolve the first item in tokens, relative to base URL; ignore the rest.

    If this fails, then jump back to the step labeled "start of line".

    If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line". If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, and the resulting absolute URL does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".

    Drop the <fragment> component of the resulting absolute URL, if it has one.

    Add the resulting absolute URL to the explicit URLs.

    If mode is "fallback"

    Let part one be the first token in tokens, and let part two be the second token in tokens.

    Resolve part one and part two, relative to base URL.

    If either fails, then jump back to the step labeled "start of line".

    If the absolute URL corresponding to either part one or part two does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".

    Drop any the <fragment> components of the resulting absolute URLs.

    If the absolute URL corresponding to part one is already in the fallback URLs mapping as a fallback namespace, then jump back to the step labeled "start of line".

    Otherwise, add the absolute URL corresponding to part one to the fallback URLs mapping as a fallback namespace, mapped to the absolute URL corresponding to part two as the fallback entry.

    If mode is "online whitelist"

    If the first item in tokens is a U+002A ASTERISK character (*), then set online whitelist wildcard flag to open and jump back to the step labeled "start of line".

    Otherwise, resolve the first item in tokens, relative to base URL; ignore the rest.

    If this fails, then jump back to the step labeled "start of line".

    If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".

    Drop the <fragment> component of the resulting absolute URL, if it has one.

    Add the resulting absolute URL to the online whitelist namespaces.

    If mode is "unknown"

    Do nothing. The line is ignored.

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

  30. Return the explicit URLs list, the fallback URLs mapping, the online whitelist namespaces, and the online whitelist wildcard flag.

If a resource is listed in the explicit section or as a fallback entry in the fallback section, the resource will always be taken from the cache, regardless of any other matching entries in the fallback namespaces or online whitelist namespaces.

When a fallback namespace and an online whitelist namespace overlap, the online whitelist namespace has priority.

The online whitelist wildcard flag is applied last, only for URLs that match neither the online whitelist namespace nor the fallback namespace and that are not listed in the explicit section.

5.6.4 어플리케이션 캐쉬의 다운로드 또는 업데이트

When the user agent is required (by other parts of this specification) to start the application cache download process for an absolute URL purported to identify a manifest, or for an application cache group, potentially given a particular cache host, and potentially given a master resource, the user agent must run the steps below. These steps are always run asynchronously, in parallel with the event loop tasks.

Some of these steps have requirements that only apply if the user agent shows caching progress. Support for this is optional. Caching progress UI could consist of a progress bar or message panel in the user agent's interface, or an overlay, or something else. Certain events fired during the application cache download process allow the script to override the display of such an interface. The goal of this is to allow Web applications to provide more seamless update mechanisms, hiding from the user the mechanics of the application cache mechanism. User agents may display user interfaces independent of this, but are encouraged to not show prominent update progress notifications for applications that cancel the relevant events.

These events are delayed until after the load event has fired.

The application cache download process steps are as follows:

  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 fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking to see if it can download the application.

    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 fire a simple event named downloading that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user the application is being downloaded.

    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 to fire a simple event that is cancelable named checking at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

    The remainder of the steps run asynchronously.

    If cache group already has an application cache in it, then this is an upgrade attempt. Otherwise, this is a cache attempt.

  3. If this is a cache attempt, then this algorithm was invoked with a cache host; queue a post-load task to fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

  4. Fetching the manifest: Fetch the resource from manifest URL with the synchronous flag set, and let manifest be that resource.

    If the resource is labeled with the MIME type text/cache-manifest, parse manifest according to the rules for parsing manifests, obtaining a list of explicit entries, fallback entries and the fallback namespaces that map to them, entries for the online whitelist, and a value for the online whitelist wildcard flag.

  5. If fetching the manifest fails due to a 404 or 410 response or equivalent, 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 fire a simple event named obsolete that is cancelable at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is no longer available for offline use.

    4. For each entry in cache group's list of pending master entries, create a task to fire a simple event that is cancelable named error (not obsolete!) at the ApplicationCache singleton of the cache host the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    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.

  6. Otherwise, if fetching the manifest fails in some other way (e.g. the server returns another 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download, or the parser for manifests fails when checking the magic signature), or if the server returned a redirect, or if the resource is labeled with a MIME type other than text/cache-manifest, then run the cache failure steps.

  7. If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in the newest application cache in cache group, or the server reported it as "304 Not Modified" or equivalent, then run these substeps:

    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 connection times out, or the user cancels the download), then create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

      Otherwise, associate the Document for this entry with cache; store the resource for this entry in cache, if it isn't already there, and categorize its entry as a master entry. If the resource's URL has a <fragment> component, it must be removed from the entry in cache (application caches never include fragment identifiers).

      HTTP caching rules, such as Cache-Control: no-store, are ignored for the purposes of the application cache download process.

    4. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named noupdate at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is up to date.

    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.

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

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

  10. Set the status of cache group to downloading.

  11. For each cache host associated with an application cache in cache group, queue a post-load task to fire a simple event that is cancelable named downloading at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is being downloaded.

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

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

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

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

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

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

    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, implementors 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 post-load task to fire an event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total attribute must be set to the number of files in file list, and the loaded attribute must be set to the number of number of files in file list that have been either downloaded or skipped so far. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS]

    3. Fetch the resource, from the origin of the URL manifest URL, with the synchronous flag set and the manual redirect flag set. If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache. User agents may also have other caches in place that are also honored.

      If the resource in question is already being downloaded for other reasons then the existing download process can sometimes be used for the purposes of this step, as defined by the fetching algorithm.

      An example of a resource that might already be being downloaded is a large image on a Web page that is being seen for the first time. The image would get downloaded to satisfy the img element on the page, as well as being listed in the cache manifest. According to the rules for fetching that image only need be downloaded once, and it can be used both for the cache and for the rendered Web page.

    4. If the previous step fails (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download), or if the server returned a redirect, then run the first appropriate step from the following list:

      If the URL being processed was flagged as an "explicit entry" or a "fallback entry"

      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 or equivalent

      Skip this resource. It is dropped from the cache.

      Otherwise

      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.

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

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

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

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

    9. As an optimization, if the resource is an HTML or XML file whose root element is an html element with a manifest attribute whose value doesn't match the manifest URL of the application cache being processed, then the user agent should mark the entry as being foreign.

  18. For each cache host associated with an application cache in cache group, queue a post-load task to fire an event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total and the loaded attributes must be set to the number of number of files in file list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that all the files have been downloaded. [PROGRESS]

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

  20. Store the URLs that form the new online whitelist in new cache.

  21. Store the value of the new online whitelist wildcard flag in new cache.

  22. 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 connection times out, or the user cancels the download), then run these substeps:

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

    2. Queue a post-load task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    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.

  23. Fetch the resource from manifest URL again, with the synchronous flag set, and let second manifest be that resource.

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

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

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

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

  28. If this is a cache attempt, then for each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named cached at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application has been cached and that they can now use it offline.

    Otherwise, it is an upgrade attempt. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named updateready at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is available and that they can activate it by reloading the page.

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

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

  31. 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 fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  3. For each cache host still associated with an application cache in cache group, create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  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, 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 Document is ready for post-load tasks

Queue the task task.

Otherwise

Add task to target's Document's list of pending application cache download process tasks.

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

5.6.5 어플리케이션 캐쉬 선택 알고리즘

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 HTTP GET or equivalent, 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.

Otherwise

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.

5.6.6 네트워크 모델의 변경

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 HTTP GET mechanism or equivalent, or if its URL has a different <scheme> component than the application cache's manifest, then fetch the resource normally and abort these steps.

  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 abort these steps.

  3. If there is an entry in the application cache's online whitelist that has the same origin as the resource's URL and that is a prefix match for the resource's URL, then fetch the resource normally and abort these steps.

  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 equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps.

  5. If the application cache's online whitelist wildcard flag is open, then fetch the resource normally and abort these steps.

  6. Fail the resource load as if there had been a generic network error.

The above algorithm ensures that so long as the online whitelist wildcard flag is blocking, resources that are not present in the manifest will always fail to load (at least, after the application cache has been primed the first time), making the testing of offline applications simpler.

5.6.7 어플리케이션 캐쉬 만료

일반적인 원칙으로, 사용자 에이전트는 어플리케이션의 유효기간을 만료시킬 수 없습니다. 이러한 것의 예외는 사용자의 요청, 혹은 연장된 기간동안 사용되지 않은 경우입니다.

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.

프라이버시 라는 관점에서 보면, 어플리케이션 캐쉬와 쿠키는 비슷한 것입니다. (다시 말해, 사이트가 캐쉬를 제공하는 시점에서 사용자를 식별할 수 있다면, 쿠키에 사용할 데이터를 캐쉬에 저장할 수 있습니다). 따라서, 브라우저 제작자들이 어플리케이션 캐쉬를 HTTP 쿠키와 연관된 방법으로 노출할 것 - 쿠키 및 기타 근원에 종속된 데이터들과 함께 어플리케이션 캐쉬를 삭제할 수 있게끔 - 을 권장합니다.

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.

5.6.8 디스크 용량

사용자 에이전트는 어플리케이션 캐쉬가 사용하는 디스크 공간에 제한을 두어야 하며, 그러한 제한사항들을 서브도메인을 이용해서 쉽게 우회하는 일이 생기지 않도록 주의를 기울여야 합니다.

User agents should consider applying constraints on disk usage of application caches, and care should be taken to ensure that the restrictions cannot be easily worked around using subdomains.

사용자 에이전트는 각각의 도메인이 얼만큼의 공간을 점유하고 있는지 볼 수 있게 해야 하며, 사용자가 특정한 어플리케이션 캐쉬를 삭제할 수 있도록 할 수 있습니다.

User agents should allow users to see how much space each domain is using, and may offer the user the ability to delete specific application caches.

이 명세에서 사용 한계선 설정을 사용자에게 어떻게 표현하는지까지 정의하지는 않습니다. 이를테면 특정 사이트들은 어플리케이션 캐쉬를 한계선의 기본값 이상으로 사용할 수 있도록 신뢰하고 있다는 점을 사용자에게 나타내는 기능 같은 것을 제공하기를 권합니다. 그러한 신뢰는 예를 들어 캐쉬가 업데이트되는 동안 비동기적으로 사용자 인터페이스를 제공한다거나, 사용자 에이전트의 설정 인터페이스에 명시적인 화이트리스트 섹션을 둔다거나 하는 방빕으로 설정할 수 있을 것입니다.

How quotas are presented to the user is not defined by this specification. User agents are encouraged to provide features such as allowing a user to indicate that certain sites are trusted to use more than the default quota, e.g. by asynchronously presenting a user interface while a cache is being updated, or by having an explicit whitelist in the user agent's configuration interface.

5.6.9 어플리케이션 캐쉬 API

interface ApplicationCache {
 
  // 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 swapCache();
 
  // events
           attribute Function onchecking;
           attribute Function onerror;
           attribute Function onnoupdate;
           attribute Function ondownloading;
           attribute Function onprogress;
           attribute Function onupdateready;
           attribute Function oncached;
           attribute Function onobsolete;
};
ApplicationCache implements EventTarget;
cache = window . applicationCache

(창에서) 그 Window의 활성 문서에 적용되는 ApplicationCache 객체를 반환합니다.

(In a window.) Returns the ApplicationCache object that applies to the active document of that Window.

cache = self . applicationCache

(공유된 워커에서) 현재의 공유된 워커에 적용되는 ApplicationCache 객체를 반환합니다. [WEBWORKERS]

(In a shared worker.) Returns the ApplicationCache object that applies to the current shared worker. [WEBWORKERS]

cache . status

다음에서 정의되는 상수에서 주어진 대로 어플리케이션 캐쉬의 현재 상태를 반환합니다.

Returns the current status of the application cache, as given by the constants defined below.

cache . update()

어플리케이션 캐쉬 다운로드를 시작합니다.

Invokes the application cache download process.

업데이트할 캐쉬가 없다면 INVALID_STATE_ERR 예외를 반환합니다.

Throws an INVALID_STATE_ERR exception if there is no application cache to update.

cache . swapCache()

가장 최근의 어플리케이션 캐쉬로 전환합니다. 그러한 것이 없다면, INVALID_STATE_ERR 예외를 반환합니다.

Switches to the most recent application cache, if there is a newer one. If there isn't, throws an INVALID_STATE_ERR exception.

이러한 것이 이미 로드된 자원을 다시 로드하는 것은 아닙니다. 예를 들어서, 이미지가 갑자기 리로드되거나, 스타일시트가 다시 파싱되거나, 스크립트가 다시 평가되는 것은 아닙니다. 이러한 요청에 의한 결과는 단지 캐쉬된 자원의 새로운 사본을 얻는 것입니다.

This does not cause previously-loaded resources to be reloaded; for example, images do not suddenly get reloaded and style sheets and scripts do not get reparsed or reevaluated. The only change is that subsequent requests for cached resources will obtain the newer copies.

There is a one-to-one mapping from cache hosts to ApplicationCache objects. The applicationCache attribute on Window objects must return the ApplicationCache object associated with the Window object's active document. The applicationCache attribute on SharedWorkerGlobalScope objects must return the ApplicationCache object associated with the worker. [WEBWORKERS]

A Window or SharedWorkerGlobalScope object has an associated ApplicationCache object even if that cache host has no actual application cache.


The status attribute, on getting, must return the current state of the application cache that the ApplicationCache object's cache host is associated with, if any. This must be the appropriate value from the following list:

UNCACHED (numeric value 0)

ApplicationCache 객체의 캐쉬 호스트가 이 시점에서 어플리케이션 캐쉬에 연결되지 않았습니다.

The ApplicationCache object's cache host is not associated with an application cache at this time.

IDLE (numeric value 1)

ApplicationCache 객체의 캐쉬 호스트가 연결된 어플리케이션 캐쉬 그룹의 업데이트 상태가 idle이며, 어플리케이션 캐쉬는 그룹에서 최신의 것이고, 그룹은 폐기된 상태가 아닙니다.

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)

ApplicationCache 객체의 캐쉬 호스트가 연결된 어플리케이션 캐쉬 그룹의 업데이트 상태가 checking 입니다.

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)

ApplicationCache 객체의 캐쉬 호스트가 연결된 어플리케이션 캐쉬 그룹의 업데이트 상태가 downloading 입니다.

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)

ApplicationCache 객체의 캐쉬 호스트가 연결된 어플리케이션 캐쉬 그룹의 업데이트 상태가 idle이며, 그룹은 폐기된 상태가 아니지만, 어플리케이션 캐쉬는 그룹에서 최신의 것이 아닙니다.

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)

ApplicationCache 객체의 캐쉬 호스트가 연결된 어플리케이션 캐쉬 그룹의 업데이트 상태가 폐기된 것입니다.

The ApplicationCache object's cache host is associated with an application cache whose application cache group is marked as obsolete.


If the update() method is invoked, the user agent must invoke the application cache download process, in the background, for the application cache with which the ApplicationCache object's cache host is associated, but without giving that cache host to the algorithm. If there is no such application cache, or if it is marked as obsolete, then the method must raise an INVALID_STATE_ERR exception instead.

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 raise an INVALID_STATE_ERR exception 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 abort these steps. (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 raise an INVALID_STATE_ERR exception and abort these steps.

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

5.6.10 브라우저 상태

window . navigator . onLine

사용자 에이전트가 명백하게 오프라인(네트워크와의 연결이 끊긴)인 경우 거짓을 반환합니다. 사용자 에이전트가 온라인일 수 있다면 참을 반환합니다.

Returns false if the user agent is definitely offline (disconnected from the network). Returns true if the user agent might be online.

이 속성의 값이 바뀔 때 online 이벤트와 offline 이벤트가 발생합니다.

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 the Window changes from true to false, the user agent must queue a task to fire a simple event named offline at the Window object.

On the other hand, when the value that would be returned by the navigator.onLine attribute of the Window changes from false to true, the user agent must queue a task to fire a simple event named online at the Window object.

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

이 속성은 신뢰할 수 없는 것입니다. 컴퓨터는 네트워크에는 연결되어 있지만 인터넷 연결은 불가능할 수 있습니다.

This attribute is inherently unreliable. A computer can be connected to a network without having Internet access.

이 예제에서는 브라우저가 온라인이 되거나 오프라인이 될 때 표시기가 업데이트됩니다.

In this example, an indicator is updated as the browser goes online and offline.

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online status</title>
  <script>
   function updateIndicator() {
     document.getElementById('indicator').textContext = 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>