W rozdziale:

• Wprowadzenie do aplikacji offline
• Manifest
• Przepływ zdarzeń
• Usuwanie błędów
• Przykład

Sztuka usuwania błędów, czyli „Zabij mnie! Zabij mnie natychmiast!”

W tej części chcę zwrócić uwagę na dwie ważne kwestie. O pierwszej już przed chwilą pisałem, ale na pewno nie zapadło ci to w pamięć, więc powtarzam: jeśli nie uda sie pobrać choćby jednego zasobu wymienionego w manifeście, w łeb weźmie cały proces buforowania aplikacji. Przeglądarka uruchomi zdarzenie error, ale nie będzie w nim wskazówki informującej,co się nie udało. Z tego powodu usuwanie błędów z aplikacji offline może być trudniejsze niż innych.

Druga ważna rzecz to coś, co może nie wydawać się błędem tylko poważną usterką przeglądarki, dopóki nie uświadomisz sobie o co tak naprawdę chodzi. Ma to związek ze sposobem sprawdzania przez przeglądarkę czy zmienił się plik manifestu. Jest to proces trzyetapowy. Nudne to, ale ważne, więc czytaj uważnie.

1. Normalnie protokół HTTP nakazuje przeglądarce sprawdzenie czy plik manifestu nie wygasł. Serwer do manifestu, podobnie jak do każdego innego typu pliku wysyłanego przy użyciu protokołu HTTP, dołącza metainformacje w nagłówkach odpowiedzi HTTP. Niektóre z tych nagłówków (Expires i Cache-Control) informują przeglądarkę w jaki sposób może buforować plik bez pytania serwera o zmiany. Ten rodzaj buforowania nie ma nic wspólnego z aplikacjami sieciowymi offline. Dotyczy ono każdego pliku HTML, CSS, JavaScript, obrazu itd.
2. Jeśli manifest wygaśnie (według jego nagłówków HTTP), przeglądarka spyta serwer, czy jest nowa wersja i jeśli tak, to pobierze go ponownie. W tym celu przeglądarka wyśle żądanie HTTP zawierające datę ostatniej modyfikacji pliku manifestu, którą serwer dodał do nagłówków odpowiedzi HTTP ostatnim razem, gdy przeglądarka pobierała manifest. Jeśli serwer stwierdzi, że manifest nie zmienił się od tego czasu, zwróci stan 304 (Not Modified). To nie ma nic wspólnego ze specyfiką aplikacji offline. Działania te są wykonywane praktycznie dla wszystkich zasobów sieciowych.
3. Jeżeli serwer uzna, że manifest się zmienił, zwróci kod stanu HTTP 200 (OK) i treść nowego pliku wraz z nowym nagłówkiem Cache-Control i datą ostatniej modyfikacji, dzięki czemu czynności 1 i 2 zostaną poprawnie wykonane następnym razem. (Protokół HTTP jest fajowski, bo serwery mogą robić plany na przyszłość. Jeśli serwer musi wysłać plik, zrobi wszystko, aby nie trzeba było go wysyłać dwa razy bez powodu. Po pobraniu nowego manifestu przeglądarka porówna jego zawartość z treścią pobranej poprzednio kopii. Jeżeli zawartość manifestu będzie taka sama, jak wcześniej, przeglądarka nie pobierze żadnego z wymienionych plików.

Na każdym z wymienionych etapów można się wyłożyć podczas tworzenia i testowania aplikacji offline. Wyobraź sobie na przykład, że tworzysz plik manifestu, a za 10 minut przypominasz sobie, że trzeba do niego dodać jeszcze jeden zasób. Nic trudnego, prawda? Wystarczy dopisać jedną linijkę kodu i gotowe. A tu Zonk: odświeżasz stronę, przeglądarka wykrywa atrybut manifest, uruchamia zdarzenie checking i… nic. Przeglądarka uparcie twierdzi, że manifest się nie zmienił. Dlaczego? Ponieważ domyślnie serwer nakazuje przeglądarkom buforowanie statycznych plików przez kilka godzin (poprzez użycie nagłówka Cache-Control protokołu HTTP). To znaczy, że przeglądarka nie wyjdzie poza pierwszy krok trzyetapowego procesu. Oczywiście serwer będzie wiedział, że plik się zmienił, ale przeglądarka go o to nawet nie spyta. Dlaczego? Ponieważ ostatnim razem gdy pobrała manifest, serwer nakazał jej zachować go w buforze przez kilka godzin (poprzez użycie nagłówka Cache-Control protokołu HTTP). I teraz po 10 minutach przeglądarka posłusznie wykonuje polecenie serwera.

Dla jasności dodam, że to nie jest błąd tylko funkcja. Wszystko działa dokładnie tak, jak powinno. Gdyby serwery nie nakazywały przeglądarkom (i pośrednikom) buforowania plików, to sieć uległaby przeciążeniu w ciągu kilku godzin. Ale to dla ciebie małe pocieszenie po kilku godzinach dociekania dlaczego przeglądarka uparła się nie wczytywać zmienionego manifestu. (Co ciekawsze, jeśli poczekasz trochę dłużej,to jakimś cudem plik manifestu wkradnie się w łaski przeglądarki! Będzie to spowodowane wygaśnięciem bufora HTTP! Dokładnie tak, jak powinno być! Zabij mnie! Zabij mnie natychmiast!)

Oto, co powinieneś zrobić: zmień konfigurację serwera tak, aby plik manifestu nie podlegał buforowaniu HTTP. Użytkownicy serwera Apache mogą dodać poniższe dwa wiersze kodu do pliku .htaccess:

ExpiresActive On
ExpiresDefault "access"

Dyrektywy te wyłączają buforowanie całego katalogu i wszystkich jego podkatalogów. Jednak w środowisku produkcyjnym nie należy tego robić, dlatego powinno się dodać dyrektywę <Files>, aby zaznaczyć że reguła dotyczy tylko manifestu albo utworzyć podkatalog zawierający tylko plik .htaccess i manifest. Oczywiście na innych serwerach konfiguracja wygląda nieco inaczej i należy poszukać w dokumentacji informacji na temat ustawiania nagłówków HTTP buforowania.

Po wyłączeniu buforowania HTTP manifestu i tak może się zdarzyć, że zmienisz jeden z zasobów w buforze aplikacji, a i tak będzie on widoczny pod tym samym adresem URL na serwerze. W tym przypadku uziemi cię drugi krok trzyetapowego procesu. Jeśli plik manifestu się nie zmieni, przeglądarka nie zauważy że zmienił się jeden z już zbuforowanych zasobów. Rozważmy poniższy przykład:

CACHE MANIFEST
# rev 42
clock.js
clock.css

Jeśli zmienisz plik clock.css i wyślesz go na serwer, zmiany nie zostaną uwzględnione, ponieważ nic nie zmieniło się w pliku manifestu. Za każdym razem gdy coś zmienisz w zasobach aplikacji offline, musisz też coś zmienić w manifeście. Może wystarczyć zmiana jednej litery. Najprostszym sposobem, jaki udało mi się wynaleźć jest dodanie komentarza z numerem wersji. Jeśli zmienisz numer wersji w komentarzu, serwer zwróci zmieniony manifest, przeglądarka zauważy, że coś się zmieniło i rozpocznie proces ponownego pobierania wszystkich zasobów.

CACHE MANIFEST
# rev 43
clock.js
clock.css

• Wprowadzenie do aplikacji offline
• Manifest
• Przepływ zdarzeń
• Usuwanie błędów
• Przykład