Jak określić symbol wieloznaczny w manifeście podręcznym HTML5, aby załadować wszystkie obrazy do katalogu?

Question

Mam wiele zdjęć w folderze, które są używane w aplikacji. Podczas używania manifestu pamięci podręcznej łatwiej byłoby zachować ostrożność, gdybym mógł określić kartę wieloznaczną, aby załadować wszystkie obrazy lub pliki w określonym katalogu, który będzie buforowany.

E.g.

CACHE MANIFEST 
# 2011-11-3-v0.1.8 
#-------------------------------- 
# Pages 
#-------------------------------- 
../index.html 
../edit.html 
#-------------------------------- 
# JavaScript 
#-------------------------------- 
../js/jquery.js 
../js/main.js 
#-------------------------------- 
# Images 
#-------------------------------- 
../img/*.png 

Czy można to zrobić? Wypróbowałem go również w kilku przeglądarkach z ../img/*, ale wydaje się, że nie działa.

Answer 1

Nie sądzę, że to działa w ten sposób. Będziesz musiał określić wszystkie obrazy jeden po drugim lub mieć prosty skrypt PHP, który przejrzy katalog i wypisze plik (oczywiście z poprawnym nagłówkiem text/cache-manifest).

Answer 2

Byłoby łatwiej, ale jak to zadziała? Plik manifestu jest czymś, co jest przetwarzane i obsługiwane w przeglądarce, która nie ma specjalnej wiedzy o plikach na twoim serwerze, poza tym, co mu powiedziałeś. Jeśli przeglądarka widzi to:

../img/*.png 

Jaki jest pierwszy obraz, który przeglądarka powinna zażądać od serwera? Zacznijmy od tych:

../img/1.png 
../img/2.png 
../img/3.png 
../img/4.png 
... 
../img/2147483647.png 

to wszystkie obrazy, które mogą występować z nazwą numeryczną, zatrzymując się w pół-arbitralnie 2³¹-1. Ile z tych 2 miliardów plików istnieje w twoim katalogu img? Czy naprawdę chcesz, aby przeglądarka wysyłała wszystkie te żądania tylko po to, aby uzyskać 2 miliardy 404? Dla kompletności przeglądarka prawdopodobnie również chcesz zwrócić wszystkie zera wypełnionych odpowiedniki:

../img/01.png 
../img/02.png 
../img/03.png 
../img/04.png 
... 
../img/001.png 
../img/002.png 
../img/003.png 
../img/004.png 
... 
../img/0001.png 
../img/0002.png 
../img/0003.png 
../img/0004.png 
... 

Teraz wykonanych ponad 4 miliardy żądań HTTP przeglądarki dla plików, które najczęściej nie istnieją, a to jeszcze nie dostałem nawet na na litery lub znaki interpunkcyjne w konstruowaniu możliwych nazw plików, które mogą istnieć na serwerze. Nie jest to realistyczny sposób działania pliku manifestu. Serwer znajduje się tam, gdzie pliki w katalogu img są znane, więc na serwerze musi zostać zbudowana lista plików.

Answer 3

Byłby to duży problem z bezpieczeństwem, gdyby przeglądarki mogły żądać listy folderów - właśnie dlatego Tomcat domyślnie wyłącza tę funkcję.

Jednak przeglądarka może zlokalizować wszystkie dopasowania do symboli wieloznacznych, do których odwołują się strony, które znajdują się w pamięci podręcznej. Takie podejście będzie nadal problematyczne (np. Co do obrazów nieużywanych początkowo, ale ustawianych dynamicznie przez JavaScript itd.) I wymagałoby, aby wszystkie elementy z pamięci podręcznej były pobierane nie tylko, ale również analizowane).

Answer 4

Jeśli próbujesz zautomatyzować ten proces, zamiast ręcznie to zrobić. Użyj skryptu lub tak jak ja używam manifestR. Wypisze plik manifestu/appcache, a wszystko, co musisz zrobić, to skopiować i wkleić. Użyłem go z powodzeniem i zwykle muszę tylko wprowadzić kilka zmian.

Również polecam przy użyciu nagłówka sieci z dziką kartą:

NETWORK: 
* 

Dzięki temu wszystkie aktywa z innych domen powiązanych pośrednictwem JSON, na przykład, aby pobrać do pamięci podręcznej. Uważam, że jest to jedyny nagłówek, w którym można określić symbol wieloznaczny. Tak jak mówili tu inni, to ze względów bezpieczeństwa.

Answer 5

Manifest pamięci podręcznej jest teraz przestarzały i do kontrolowania buforowania należy używać nagłówków HTML.

Na przykład:

<meta http-equiv="Cache-control" content="public"> 

• publiczny - mogą być przechowywane w pomieszczeniach udostępnionych skrytek.
• Prywatne - może być buforowane tylko w prywatnej pamięci podręcznej.
• Brak bufora - nie można buforować.
• No-Store - może być buforowany, ale nie zarchiwizowany.