Zasoby offline w Firefoksie

Firefox 3.5 wspiera standard HTML 5 umożliwiający zbieranie podręcznej pamięci zasobów internetowych offline. Dzieje się tak dzięki pamięci podręcznej aplikacji (pochodzącej z manifestu zasobów dostarczonego przez przeglądarkę internetową).

Terminologia

W tej sekcji zostało zdefiniowane kilka terminów, które ułatwią zrozumienie dokumentacji.

manifest pamięci podręcznej

Plik opisujący zasoby, które powinny być zachowane do użytku w trybie offline.

ID klienta

ID klienta używane przez interfejs nsICacheService podczas zarządzania pamięcią podręczną aplikacji. Jest to nieprzezroczysty łańcuch znaków, tworzony podczas powstawania pamięci podręcznej nowej aplikacji.

grupa pamięci podręcznej

Zestaw różnych wersji dla tego samego manifestu pamięci podręcznej.

ID grupy

URI pliku manifestu pamięci podręcznej. Wszystkie pamięci podręczne współdzielące tą samą pamięć, są w tej samej grupie pamięci podręcznej.

Pamięć podręczna aplikacji

Wszystkie manifesty zasobów aplikacji internetowych posiadają własną pamięć podręczną aplikacji. Od czasu gdy programy zaczynają współdzielić zasoby (mogą także posiadać takie same manifesty URI), pamięć podręczna aplikacji oddziela kopie wszystkich dzielonych zasobów. Wersje pamięci podręcznych są zapisywane - za każdym razem, gdy dana strona jest odwiedzana online, aplikacji dołącza nową wersję do pamięci podręcznej. Powstała wersja jest używana przy kolejnej wizycie na stronie.

Sposób działania pamięci podręcznej

Pamięć podręczna aplikacji modyfikuje proces wczytywania dokumentu. Elementy z pamięci podręcznej są wykorzystywane bez łączenia się z internetem (inaczej niż w przypadku aktualizacji kopii aplikacji internetowej w pamięci podręcznej - przebiega to w tle i nie ma dużego wpływu na szybkość).

Niektóre elementy pamięci podręcznej mogą być nieaktualne. Gdy manifest został usunięty z sewera, Firefox usuwa wszystkie składniki pamięci podręcznej używające tego manifestu, po czym wysyła "przestarzałe" zdarzenie do obiektu pamięci podręcznej aplikacji. Następnie, status pamięci podręcznej zyskuje wartość OBSOLETE.

Przykład działania

This section offers an example of the work flow of how loading a page works with the cache.  If you're an end user of the caching mechanism, you don't really need to know this, but it's useful if you're developing Firefox or embedding Gecko.

Let's assume you have a cache manifest located at https://www.foo.com/cache.manifest, which includes two resources: test.html and test.png.  Loading test.html results in the following steps being taken:

The HTTP channel calls the nsIApplicationCacheService method nsIApplicationCacheService.chooseApplicationCache() to select the appropriate group ID for the requested resource:

appCache = nsIApplicationCacheService::ChooseApplicationCache("https://www.foo.com/test.html");

This returns the most recent application cache in the group identified by group ID "https://www.foo.com/cache.manifest".  Then, the HTTP channel does something similar to the following:

cacheSession = nsICacheSerivce::CreateSession(appCache.clientID, STORAGE_OFFLINE, true);
cacheEntry = cacheSession.openCacheEntry("https://www.foo.com/test.html");

This creates a cache session and opens the requested resource from within the cache.  From this point on, it loads the data from cacheEntry, but without validation.

When test.html is loading, the docshell tells sub-loads to use the same application cache that was found by the call to chooseApplicationCache(), so that any resources loaded by test.html will also be loaded from the same cache.

Pamięć podręczna aplikacji

Każda pamięć podręczna aplikacji posiada status, który definiuje aktualny stan pamięci. Pamięci, które wspóldzielą ten sam manifest URI, współdzielą także ten sam status. Rodzaje statusów:

UNCACHED

Specjalny znacznik oznaczający, że obiekt pamięci podręcznej nie jest w pełni zainicjowany.

IDLE

Pamięć podręczna nie jest w trakcie procedury aktualizacji.

CHECKING

Manifest sprawdza bądź pobiera aktualizacje.

DOWNLOADING

Zasoby są pobierane, towarzyszy temu dodanie do pamięci podręćznej i zmiana manifestu zasobu.

UPDATEREADY

Dostępna jest nowa wersja podręcznej pamięci. Odebrano zdarzenie updateready, które jest wywoływane nawet gdy pojawi się zdarzenie cached podczas gdy aktualizacja została pobrana, lecz jeszcze nie zaaktywowana metodą swapCache().

OBSOLETE

Grupa pamięci podręcznej jest nieaktualna.

Zasoby w pamięci podręcznej

Pamięć podręczna zawsze dołącza najmniejszy zasób, identyfikowany przez URI. Wszystkie zasoby dzielą się na poniższe kategorie:

Główne elementy

These are resources added to the cache because a browsing context visited by the user included a document that indicated that it was in this cache using its manifest attribute.

Manifest

This is the resource manifest itself, loaded from the URI specified in an implicit entry's html element's manifest attribute. The manifest is downloaded and processed during the application cache update process. Implicit entries must have the same scheme, host, and port as the manifest.

Lista elementów

These are resources listed in the cache's manifest.

Fallback entries

These are resources that were listed in the cache's manifest as fallback entries.

Główne elementy

Są to wszelkie pliki HTML zawierające atrybut manifestu wewnątrz elementu <html>. Przykładowo, załóżmy, że mamy plik HTML https://www.foo.bar/entry.html, który wygląda następująco:

<html manifest="foo.manifest">
<h1>Entry</h1>
</html>

Jeśli entry.html nie jest dołączony do manifestu, odwiedzenie strony entry.html spowoduje dodanie pliku entry.html do pamięci podręcznej jako główny element.

Fallback entries

Fallback entries are used when an attempt to load a resource fails.  For example, imagine that there is a cache manifest located at https://www.foo.bar/test.manifest, with the following contents:

CACHE MANIFEST
FALLBACK:
foo/bar/ foo.html

Any request to https://www.foo.bar/foo/bar/ or its subdirectories and their contents will cause a network request to attempt to load the requested resource.  If the attempt fails, either due to a network failure or a server error of some kind, the contents of the file foo.html are loaded instead.

Biała lista online

The online whitelist may contain zero or more URIs of resources that the web application will need to access off the server rather than the offline cache. This lets the browser's security model protect the user from potential security breaches by limiting access only to approved resources.

This lets you ensure that, for example, scripts and other code is loaded and executed from the server instead of the cache:

CACHE MANIFEST
NETWORK:
/api

This ensures that requests to load resources contained in the https://www.foo.bar/api/ subtree will always go to the network without attempting to access them from the cache.

Manifest pamięci podręcznej

Cache manifest files must be served with the text/cache-manifest MIME type, and all resources served using this MIME type must follow the syntax for an application cache manifest, as defined here. Cache manifests are UTF-8 format text files and may, optionally, include a BOM character. Newlines may be represented by line feed (U+000A), carriage return (U+000D), or carriage return and line feed both.

The first line of the cache manifest must consist of the string "CACHE MANIFEST" (with a single U+0020 space between the two words), followed by zero or more space or tab characters. Any other text on the line will be ignored.

The remainder of the cache manifest must be comprised of zero or more of the following lines:

Pusta linia

Możesz użyć pustej linii zawierającej zero bądź tzw. "białe znaki" (spacje, tabulatory).

Komentarz

Comments consist of zero or more tabs or spaces followed by a single "#" character, followed by zero or more characters of comment text. Comments may only be used on their own lines, and cannot be appended to other lines.

Nagłówek sekcji

Section headers specify which section of the cache manifest is being manipulated. There are three possible section headers:

Sekcja nagłówkowa	Opis
CACHE:	Zmienia na sekcję list. To jest domyślna sekcja.
FALLBACK:	Switches to the fallback section. Uwaga dotycząca Firefoksa 3.1 The fallback section is ignored by versions of Firefox prior to 3.1.
NETWORK:	Zmienia na sekcję białą listę online. Uwaga dotycząca Firefoksa 3.1 Biała lista online jest ignorowana w wersjach Firefox wcześniejszych od 3.1.

Linia nagłówka sekcji może zawierać białe znaki, ale musi także posiadać dwukropek w nazwie sekcji.

Dane dla bieżącej sekcji

The format of data lines varies from section to section. In the explicit section, each line is a valid URI or IRI reference to a resource to cache. Whitespace is allowed before and after the URI or IRI on each line.

Cache manifests may switch back and forth from section to section at will (so each section header can be used more than once), and sections are allowed to be empty.

Przykład manifestu pamięci podręcznej

Przykład dla wymyślonej strony internetowej foo.com.

CACHE MANIFEST
# v1
# To jest komentarz.
https://www.foo.com/index.html
https://www.foo.com/header.png
https://www.foo.com/blah/blah

In this example, there is no section header, so all data lines are assumed to be in the explicit section.

The "v1" comment is there for a good reason. Because the cache is only updated when the manifest changes, if you change the resources (for example, updating the header.png image with new content), you need to change the manifest file in order to let the browser know that it needs to refresh the cache. You can do this by any tweak to the manifest, but having a version number is a good way to do it.

Specyfikacja manifestu pamięci podręcznej

Aby poinformować Firefoksa o używaniu pamięci podręcznej offline dla danej strony internetowej, strona ta musi posiadać atrybut manifest wewnątrz znaczników html:

<html manifest="https://www.foo.com/cache-manifest">
  ...
</html>

Procedura aktualizacji

1. When Firefox visits a document that includes a manifest attribute, it sends a checking event to the window.applicationCache object, then fetches the manifest file, following the appropriate HTTP caching rules. If the currently-cached copy of the manifest is up-to-date, the noupdate event is sent to the applicationCache, and the update process is complete.
2. If the manifest file hasn't changed since the last update check, again, the noupdate event is sent to the applicationCache, and the update process is complete. Again, this is why if you change the resources, you need to change the manifest file so Firefox knows it needs to re-cache the resources.
3. If the manifest file has changed, all files in the manifest -- as well as those added to the cache by calling applicationCache.add() -- are fetched into a temporary cache, following the appropriate HTTP caching rules. For each file fetched into the cache, a progress event is sent to the applicationCache object. If any errors occur, an error event is sent, and the update halts.
4. Once all the files have been successfully retrieved, they are moved into the real offline cache atomically, and a cached event is sent to the applicationCache object.

Zobacz również

• HTML 5 working draft: Offline web applications 
• nsIApplicationCache
• nsIApplicationCacheNamespace
• nsIApplicationCacheContainer
• nsIApplicationCacheChannel
• nsIApplicationCacheService
• nsIDOMOfflineResourceList
• Get ready for Firefox 3.0 - A Web developer's guide to the many new features in this popular browser, especially the offline application features (IBM developerWorks)