2011-01-18 18 views
6

Mam aplikację szyny, którą próbuję uzyskać za pomocą buforowania aplikacji HTML5 za pomocą Rack :: Offline. Plik application.manifest został skonfigurowany i jest pobierany i sprawdzany na mojej stronie HTML. Manifest wygląda następująco:Plik manifestu HTML5 nie czyści pamięci podręcznej po zmianie manifestu

CACHE MANIFEST 
# 2d9bf2b03a07dc960fd8fe69659ceeffd4d28ccf8619669a506c3682bf223878 
404.html 
422.html 
500.html 
login.html 
stylesheets/scaffold.css 
javascripts/jquery.min.js 
javascripts/jquery.js 
javascripts/application.js 
javascripts/rmbz.js 
javascripts/rails.js 
images/rails.png 

NETWORK: 
/

Strona mam dostępu jest localhost: 3000/mobile, i to buforowane cudownie (widoczna kiedy zdjąć serwer szyn). Zmienił się jednak plik application.manifest, do którego się odwołuje (w rzeczywistości zmienia się przy każdym żądaniu, manipulując skomentowanym identyfikatorem szesnastkowym), ale Chrome nie aktualizuje strony. W logu konsoli Chrome znajduje się:

Document was loaded from Application Cache with manifest http://localhost:3000/application.manifest 
Application Cache Checking event 
Application Cache Downloading event 
Application Cache Progress event (0 of 12) http://localhost:3000/login.html 
Application Cache Progress event (1 of 12) http://localhost:3000/404.html 
Application Cache Progress event (2 of 12) http://localhost:3000/422.html 
Application Cache Progress event (3 of 12) http://localhost:3000/javascripts/rails.js 
Application Cache Progress event (4 of 12) http://localhost:3000/javascripts/rmbz.js 
Application Cache Progress event (5 of 12) http://localhost:3000/images/rails.png 
Application Cache Progress event (6 of 12) http://localhost:3000/500.html 
Application Cache Progress event (7 of 12) http://localhost:3000/javascripts/jquery.js 
Application Cache Progress event (8 of 12) http://localhost:3000/stylesheets/scaffold.css 
Application Cache Progress event (9 of 12) http://localhost:3000/javascripts/jquery.min.js 
Application Cache Progress event (10 of 12) http://localhost:3000/mobile 
Application Cache Progress event (11 of 12) http://localhost:3000/javascripts/application.js 
Application Cache Error event: Manifest changed during update, scheduling retry 

Nie bardzo rozumiem, dlaczego to się nie udaje. Wydaje się, że robi wszystko, co powinno, aż do ostatniej linii! Dostaję podobny dziennik, jeśli poruszam się w przeglądarce do localhost: 3000/application.manifest - wygląda na to, że manifest jest buforowany, więc czy może dlatego, że manifest się zmienił? Jakieś pomysły?

Dzięki!

+0

kiedykolwiek to rozwiązane? Poniższe odpowiedzi nie są pomocne. –

+0

Naprawiono problem i udzielono odpowiedzi poniżej. Mam nadzieję, że jest to przydatne, jeśli jeszcze tego nie naprawiłeś. –

Odpowiedz

1

miałem ten sam problem, musiał wprowadzić zmiany do samego klejnotu . Mój problem polegał na zagnieżdżaniu folderów w/public/images

Zacznij od znalezienia miejsca, w którym są zainstalowane twoje klejnoty ("gem environment" to dostaniesz) i przejdź do /rack-offline-0.6.1/lib.

Edytuj plik rack-offline.rb. Usuń linię 33 i zastąp:

"#{root}/images/**/*.png", 
"#{root}/images/**/*.jpg", 
"#{root}/images/**/*.gif"] 

Zrestartuj serwer szyn i spróbuj ponownie. Pracowałem dla mnie, mam nadzieję, że ci to pomoże.

2

Ostatni żądany przez Chrome plik to application.manifest, jeśli zmieniło się to od pierwotnego żądania (tak jak mówisz), to unieważnia pamięć podręczną. Zachowaj manifest bez zmian, dopóki nie zmieni się jeden z plików wymienionych w manifeście.

+0

Cześć Robert. Czy zmiana w manifeście nie powinna po prostu zachęcić Chrome do pobrania wszystkiego z pliku manifestu? Wydaje mi się, że samouczek, który obserwuję, brzmi: http://asciicasts.com/episodes/247-offline-apps-part-1): "Kiedy zmienia się hash, informuje przeglądarkę, że manifest cache się zmienił i że pliki, które wymienia, muszą zostać pobrane ponownie. Tak będzie w przypadku każdego żądania w trybie programistycznym, ale w przypadku produkcji nastąpi tylko, gdy jeden z plików ulegnie zmianie. " – kmc

+0

@kmc Tak, a ponieważ ostatnią rzeczą do pobrania jest manifest (ponownie), a ten manifest się zmienił, to pamięć podręczna plików, które właśnie pobrano, jest unieważniana. Możesz to sprawdzić, patrząc na dziennik serwera (który prawdopodobnie wyprowadza się na konsolę?). Nie mam pojęcia o bibliotece, której używasz, ale jeśli zmienia ona plik manifestu, gdy nie ma żadnych zmian w plikach w manifeście, to nie zadziała. – robertc

2

To dzieje się w trybie programowania Railsów za każdym razem, ponieważ domyślnie klucz jest odnawiany za każdym razem, gdy strona zostanie trafiona. Możesz obejść ten problem, ustawiając cache_classes na true w environments/development.rb. Należy jednak pamiętać, że cache_classes nie jest specyficzne dla Rack::Offline. Możesz więc uzyskać nieoczekiwane zachowanie w środowisku programistycznym, jeśli wprowadzisz zmianę.

3

Rack :: Offline wydaje się używać okna czasowego do odświeżania skrótu w pliku manifestu (lib/rack/offline.rb: 84).

now = Time.now.to_i - Time.now.to_i % @cache_interval 

# @cache_interval defaults to 10 seconds 

Plik manifestu jest żądany dwa razy przez przeglądarkę: raz na początku żądania i gdy wszystkie pamięci podręczne zostały pomyślnie zapisane w trybie offline.

Podczas obsługi zgłoszenia zajmuje dużo czasu (wiele zasobów musi być załadowanych) może się zdarzyć, że pierwsze żądanie zostanie odebrane w jednym oknie czasowym, a ostateczne żądanie jest obsługiwane w innym.W konsekwencji skróty w obu manifestach nie będą się zgadzać i w rezultacie otrzymasz komunikat "Błąd aplikacji Cache Error: Manifest changed during update, schedulre remry".

Aby zmniejszyć szanse takiego błędu podczas rozwoju możesz ustawić większą cache_interval następująco:

offline = Rack::Offline.configure :cache_interval => 20 do 
    ... 
end 
Powiązane problemy