Wymuś wyczyszczenie pamięci podręcznej przeglądarki

283

Czy mogę w jakiś sposób umieścić kod na mojej stronie, aby gdy ktoś odwiedził witrynę, wyczyścił pamięć podręczną przeglądarki, aby mógł zobaczyć zmiany?

Użyte języki: ASP.NET, VB.NET i oczywiście HTML, CSS i jQuery.

Adam
źródło
Ładne rozwiązanie lub obejście „czyszczenia pamięci podręcznej” można znaleźć tutaj: stackoverflow.com/a/43676353/2008111
caramba

Odpowiedzi:

350

Jeśli tak jest .cssi .jszmienia się, jednym ze sposobów na „pomijanie pamięci podręcznej” jest dodanie czegoś takiego jak „ _versionNo” do nazwy pliku dla każdej wersji. Na przykład:

script_1.0.css // This is the URL for release 1.0
script_1.1.css // This is the URL for release 1.1
script_1.2.css // etc.

Lub alternatywnie zrób to po nazwie pliku:

script.css?v=1.0 // This is the URL for release 1.0
script.css?v=1.1 // This is the URL for release 1.1
script.css?v=1.2 // etc.

Możesz sprawdzić ten link, aby zobaczyć, jak to może działać.

Fermin
źródło
10
Jest to dość dobre rozwiązanie i może nawet zostać zautomatyzowane przez system kompilacji (i powinno być). Na przykład Stackoverflow korzysta z tego podejścia.
derobert,
7
SO używa teraz argumentów GET.
Saeb Amini,
60
Jeszcze lepiej jest zachować obecną nazwę pliku, ale dołączyć numer wersji jako parametr zapytania, tj script.js?v=1.2. (Lub jeśli nie śledzisz wersji, użyj czasu ostatniej modyfikacji pliku, co jest jeszcze łatwiejsze do zrobienia). Nie jestem pewien, czy to właśnie miał na myśli poprzedni komentator!
Doin
5
Jak wszyscy to robią z kontrolą wersji? Wygląda na prawdziwy ból.
Shawn
1
@Shawn Jeśli chodzi o kontrolę wersji, możesz <link />dynamicznie renderować tagi i wstrzykiwać wersję aplikacji jako parametr ciągu zapytania. Alternatywnie, niektóre CMSy będą miały „wersję zasobów klienta” jako dołączone ustawienie dla całego CMS - administrator witryny może ręcznie zwiększyć tę wersję nr, a aktualizacje CMS mogą również automatycznie ją zaktualizować. Konkluzja: musisz dynamicznie renderować adresy URL plików.
Jeroen
103

Zajrzyj do kontroli pamięci podręcznej, a tag META utraci ważność .

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">

Inną powszechną praktyką jest dołączanie ciągle zmieniających się ciągów na końcu żądanych plików. Na przykład:

<script type="text/javascript" src="main.js?v=12392823"></script>

Sampson
źródło
44
Nie pomoże to w przypadku, gdy jest już w pamięci podręcznej - ponieważ jest w pamięci podręcznej, serwer nie zostanie zapytany, a zatem nie będzie mógł odpowiedzieć bez pamięci podręcznej. Ponadto, ten metatag naprawdę nie powinien być używany, ponieważ notatka mówi, że zepsuje się z buforami internetowymi.
derobert,
1
+1 co powiedział derobert. Zawsze lepiej jest używać nagłówków HTTP do sugerowania zasad buforowania klientom i pamięci podręcznej, ale nawet to nie działa, aby wymusić ponowne załadowanie bufora.
4
+1 za drugie rozwiązanie. Mam problem polegający na tym, że pamięć podręczna powinna zostać wyczyszczona tylko za pierwszym razem po aktualizacji dokonanej przez administratora. To podejście powinno rozwiązać ten problem
Jules Colle,
Całkowite wyłączenie pamięci podręcznej jest zwykle bardzo złym pomysłem.
Jordan
73

Aktualizacja 2012

To stare pytanie, ale myślę, że wymaga ono bardziej aktualnej odpowiedzi, ponieważ teraz istnieje sposób na większą kontrolę nad buforowaniem stron internetowych.

W aplikacjach internetowych offline (czyli tak naprawdę dowolnej witrynie HTML5)applicationCache.swapCache() można używać do aktualizowania wersji witryny z pamięci podręcznej bez konieczności ręcznego przeładowywania strony.

Oto przykład kodu z Przewodnika dla początkujących na temat używania pamięci podręcznej aplikacji w HTML5 Rocks, wyjaśniający, jak zaktualizować użytkowników do najnowszej wersji witryny:

// Check if a new cache is available on page load.
window.addEventListener('load', function(e) {

  window.applicationCache.addEventListener('updateready', function(e) {
    if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
      // Browser downloaded a new app cache.
      // Swap it in and reload the page to get the new hotness.
      window.applicationCache.swapCache();
      if (confirm('A new version of this site is available. Load it?')) {
        window.location.reload();
      }
    } else {
      // Manifest didn't changed. Nothing new to server.
    }
  }, false);

}, false);

Zobacz także Korzystanie z pamięci podręcznej aplikacji w Mozilla Developer Network, aby uzyskać więcej informacji.

Aktualizacja 2016

Rzeczy szybko się zmieniają w sieci. To pytanie zostało zadane w 2009 r., Aw 2012 r. Opublikowałem aktualizację dotyczącą nowego sposobu rozwiązania problemu opisanego w pytaniu. Minęły kolejne 4 lata i teraz wydaje się, że jest już przestarzałe. Dzięki cgaldiolo za wskazanie tego w komentarzach.

Obecnie, od lipca 2016 r., HTML Standard, sekcja 7.9, Offline aplikacje internetowe zawiera ostrzeżenie o wycofaniu:

Ta funkcja jest właśnie usuwana z platformy internetowej. (Jest to długi proces, który trwa wiele lat.) Odradza się obecnie korzystanie z dowolnych funkcji aplikacji internetowych offline. Zamiast tego użyj pracowników serwisu.

Podobnie jest z używaniem pamięci podręcznej aplikacji w sieci Mozilla Developer Network, do której odwoływałem się w 2012 roku:

Przestarzałe
Ta funkcja została usunięta ze standardów internetowych. Chociaż niektóre przeglądarki mogą go obsługiwać, jest on w trakcie usuwania. Nie używaj go w starych lub nowych projektach. Korzystające z niego strony lub aplikacje internetowe mogą w dowolnym momencie ulec awarii.

Zobacz także Błąd 1204581 - Dodaj powiadomienie o wycofaniu AppCache, jeśli włączono przechwytywanie pobierania pracownika usługi .

rsp
źródło
1
Czy to oznacza, że ​​musisz używać i utrzymywać plik manifestu w pamięci podręcznej?
Sam
Ostrzeżenie: interfejs pamięci podręcznej aplikacji (AppCache) został wycofany
cgaldiolo,
59
Więc jakie jest obecne zalecenie z 2017 roku?
Garrett
głównym problemem, jaki widziałem w tym temacie, jest to, że urządzenie, którego używa przeglądarka, nadal korzysta z wersji buforowanych, ponieważ pamięć wewnętrzna urządzenia użytkownika się zapełnia. wydaje się, że utknął na buforowanej wersji strony i nie aktualizuje żadnych elementów w dokumencie. czy dzieje się tak tylko w chromie? to jedyna przeglądarka, w której kiedykolwiek go widziałem.
user2585548
4
2017: Użyj pracowników serwisu.
digitai
27

Nie jako taki. Jedną z metod jest wysłanie odpowiednich nagłówków podczas dostarczania treści, aby zmusić przeglądarkę do ponownego załadowania:

Upewnienie się, że strona internetowa nie jest buforowana we wszystkich przeglądarkach.

Jeśli szukasz "cache header" lub coś podobnego tutaj na SO, znajdziesz przykłady specyficzne dla ASP.NET.

Innym, mniej czystym, ale czasem jedynym sposobem, jeśli nie można kontrolować nagłówków po stronie serwera, jest dodanie losowego parametru GET do wywoływanego zasobu:

myimage.gif?random=1923849839
Pekka
źródło
2
Naprawdę lepiej jest poprawnie zaktualizować pliki. Jest to dość duża strata przepustowości i, co ważniejsze, znacznie spowalnia twoją witrynę.
derobert,
8
To naprawdę zależy od sytuacji, prawda? Jeśli programujesz CMS i musisz upewnić się, że wszystkie zmienione zasoby są odpowiednio zaktualizowane, czasami nie ma możliwości obejścia jednej z tych dwóch opcji.
Pekka
Takie rozwiązania powinny być przegłosowane negatywnie. To od nas zależy, aby ślad CO2 w Internecie był jak najniższy.
czas
14

W przypadku zasobów statycznych właściwym buforowaniem byłoby użycie parametrów zapytania o wartości każdego wdrożenia lub wersji pliku. Spowoduje to wyczyszczenie pamięci podręcznej po każdym wdrożeniu.

/Content/css/Site.css?version={FileVersionNumber}

Oto przykład ASP.NET MVC.

<link href="@Url.Content("~/Content/Css/Reset.css")[email protected]().Assembly.GetName().Version" rel="stylesheet" type="text/css" />

Nie zapomnij zaktualizować wersji zestawu.

Paulius Zaliaduonis
źródło
Dziękuję za tę odpowiedź, ale jak to zrobić, kiedy dodamy zasoby w tabeli pakietów?
toregua,
W moim przypadku zwracana była wersja „0.0.0.0”. Aby uzyskać wersję biblioteki DLL swojej aplikacji MVC, użyj jej zamiast tego:[email protected]().Assembly.GetName().Version
CGodo
1
Przekonałem się, że to uniemożliwia całkowite buforowanie zawartości przez Firefox i Chrome.
Sam
10

Miałem podobny problem i tak go rozwiązałem:

  1. W index.htmlpliku dodałem manifest:

    <html manifest="cache.manifest">
  2. W <head>sekcji zawarto skrypt aktualizujący pamięć podręczną:

    <script type="text/javascript" src="update_cache.js"></script>
  3. W <body>sekcji wstawiłem funkcję onload:

    <body onload="checkForUpdate()">
  4. W cache.manifestumieściłem wszystkie pliki, które chcę buforować. Ważne jest teraz, że działa w moim przypadku (Apache), po prostu aktualizując za każdym razem komentarz „wersja”. Jest także opcja nazywania plików za pomocą „? Ver = 001” lub czegoś na końcu nazwy, ale nie jest to konieczne . Zmiana tylko # version 1.01wyzwala zdarzenie aktualizacji pamięci podręcznej.

    CACHE MANIFEST
    # version 1.01
    style.css
    imgs/logo.png
    #all other files

    Ważne jest, aby uwzględniać 1., 2. i 3. punkty tylko w index.html. Inaczej

    GET http://foo.bar/resource.ext net::ERR_FAILED

    występuje, ponieważ każdy plik „podrzędny” próbuje buforować stronę, gdy strona jest już buforowana.

  5. W update_cache.jspliku umieściłem ten kod:

    function checkForUpdate()
    {
        if (window.applicationCache != undefined && window.applicationCache != null)
        {
            window.applicationCache.addEventListener('updateready', updateApplication);
        }
    }
    function updateApplication(event)
    {
        if (window.applicationCache.status != 4) return;
        window.applicationCache.removeEventListener('updateready', updateApplication);
        window.applicationCache.swapCache();
        window.location.reload();
    }

Teraz po prostu zmieniasz pliki i oczywiście musisz zaktualizować komentarz do wersji. Teraz odwiedzając stronę index.html zaktualizujesz pamięć podręczną.

Części rozwiązania nie są moje, ale znalazłem je przez Internet i zestawiłem tak, aby działało.

Wojtek Mazurek
źródło
Czy mogę wiedzieć, gdzie jest napisany CACHE.MANIFEST.
Shweta Gulati
1
Shweta Gulati Plik manifestu powinien znajdować się w tym samym folderze co plik „indeksu”. W jakich godzinach to nie działa?
Wojtek Mazurek
1
@ShwetaGulati Tak, pamięć podręczna nie wykrywa zmian w plikach HTML - dlatego musisz zaktualizować numer wersji w pliku manifestu, ponieważ to on jest sprawdzany pod kątem zmian. Naprawdę trudno ci pomóc, ponieważ nie znam szczegółów. Proszę, powiedz mi, czy umieściłeś wszystkie żądane pliki w pamięci podręcznej w manifeście? Ścieżka powinna być względna do pliku manifestu. Możesz podać mi adres swojej witryny, a ja mogę powiedzieć, o co chodzi :)
Wojtek Mazurek
1
@ShwetaGulati Jest tak, ponieważ przeglądarka automatycznie buforuje niektóre pliki, aby przyspieszyć ładowanie strony. Jest to zachowanie domyślne i zależy tylko od przeglądarki, więc nie można go w żaden sposób ustawić. Zwłaszcza pliki js znajdują się w zakresie przeglądarki, ponieważ są zwykle używane na wszystkich stronach witryny, dlatego dobrze jest je buforować. Nie ma innego sposobu niż zapisanie wszystkich nazw plików w pliku manifestu w celu buforowania wszystkich plików. Jeśli znajdziesz, powiedz mi, bo ja też go potrzebuję :)
Wojtek Mazurek
1
Bezwzględna ścieżka do twoich plików nie ma znaczenia. Ścieżka względna z adresu ma znaczenie, ponieważ przeglądarka wysyła żądanie plików. F.ex: Mam domenę example.com i jest ona na serwerze names.com. Moje miejsce na nim to example.names.com. Dołączam więc moją domenę example.com do przestrzeni serwera example.names.com jako przekierowanie. Aby to zrobić, muszę ustawić folder jako cel tego przekierowania. Więc jeśli chcę mieć kilka witryn na example.names.com, tworzę folder „name1”, ustawiam przekierowanie do niego i umieszczam w nim wszystkie moje pliki. Ścieżki są liczone stąd. Jeśli mam plik name1 \ scripts \ test.js w pliku manifestu, piszę scripts \ test.js.
Wojtek Mazurek
7

Miałem przypadek, w którym robiłem zdjęcia klientom online i musiałbym zaktualizować div, jeśli zdjęcie zostanie zmienione. Przeglądarka wciąż wyświetlała stare zdjęcie. Wykorzystałem więc hack wywołania losowej zmiennej GET, która za każdym razem byłaby unikalna. Tutaj jest, jeśli to może komukolwiek pomóc

<img src="/photos/userid_73.jpg?random=<?php echo rand() ?>" ...

EDYCJA Jak zauważyli inni, poniższe jest znacznie bardziej wydajnym rozwiązaniem, ponieważ przeładuje obrazy tylko wtedy, gdy zostaną zmienione, identyfikując tę ​​zmianę według rozmiaru pliku:

<img src="/photos/userid_73.jpg?modified=<? filemtime("/photos/userid_73.jpg")?>"
zeeshan
źródło
29
To wcale nie jest eleganckie, spowodowałoby to, że strona przeładowuje obraz za każdym razem, gdy marnuje się dużo czasu na pobieranie zasobów, lepszym rozwiązaniem byłoby użycie rozmiaru pliku zamiast losowej liczby, dzięki czemu pamięć podręczna zostanie ponownie sprawdzona tylko wtedy, gdy plik faktycznie zmiany
Roberto Arosemena,
8
Lub skrót bajtów obrazu
Taylor Edmiston
1
Wszystko zależy od wymagań użytkownika. W przypadku dużej liczby zdjęć scenariusz byłby inny niż kilka zdjęć. Sprawdzanie rozmiaru pliku pozwoliłoby zaoszczędzić przepustowość, ale także dodałoby dodatkowe przetwarzanie, potencjalnie spowalniając ładowanie strony. W moim przypadku, gdy zdjęcia zmieniały się dość często i decyzja biznesowa, że ​​użytkownik otrzyma najbardziej aktualne, była bardzo ważna, było to idealne rozwiązanie.
zeeshan
Można nawet ustawić wartość statyczną w konfiguracji, nie jest to w żadnym razie idealne podejście.
Widzący
3
<img src = "/ photos / userid_73.jpg? zmodyfikowano = <? = filemtime (" / photos / userid_73.jpg ")?>" byłoby znacznie bardziej przydatne!
Fusca Software
4

Wiele odpowiedzi nie ma sensu - większość programistów zdaje sobie sprawę, że wyłączenie pamięci podręcznej jest nieefektywne. Jednak istnieje wiele typowych okoliczności, w których wydajność nie jest ważna, a domyślne zachowanie pamięci podręcznej jest poważnie zepsute.

Obejmują one zagnieżdżone, iteracyjne testowanie skryptów (duże!) I zepsute obejścia oprogramowania innych firm. Żadne z podanych tutaj rozwiązań nie jest odpowiednie, aby rozwiązać takie powszechne scenariusze. Większość przeglądarek internetowych jest zbyt agresywnym buforowaniem i nie zapewnia rozsądnych sposobów uniknięcia tych problemów.

Jan
źródło
2

Aktualizacja adresu URL do następującego działa dla mnie:

/custom.js?id=1

Dodając unikalny numer po ?id=i zwiększając go o nowe zmiany, użytkownicy nie muszą naciskać, CTRL + F5aby odświeżyć pamięć podręczną. Alternatywnie możesz dołączyć wersję hash lub string bieżącej godziny lub Epoki po?id=

Coś jak ?id=1520606295

nPcomp
źródło
1

Oto strona MDSN na temat ustawiania buforowania w ASP.NET.

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)
Response.Cache.SetValidUntilExpires(False)
Response.Cache.VaryByParams("Category") = True

If Response.Cache.VaryByParams("Category") Then
   '...
End If
Dave Swersky
źródło
1

Nie jestem pewien, czy to naprawdę może ci pomóc, ale tak właśnie powinno działać buforowanie w dowolnej przeglądarce. Gdy przeglądarka żąda pliku, powinna zawsze wysyłać żądanie do serwera, chyba że istnieje tryb „offline”. Serwer odczyta niektóre parametry, takie jak data modyfikacji lub etagi.

Serwer zwróci odpowiedź 304 o błędzie NIEZMODYFIKOWANY, a przeglądarka będzie musiała użyć pamięci podręcznej. Jeśli etag nie sprawdza się po stronie serwera lub data modyfikacji jest niższa od bieżącej daty modyfikacji, serwer powinien zwrócić nową treść z nową datą modyfikacji lub etagami lub obydwoma.

Jeśli do przeglądarki nie są wysyłane żadne dane buforowania, myślę, że zachowanie nie jest określone, przeglądarka może buforować plik, który nie informuje o tym, jak są buforowane. Jeśli w odpowiedzi ustawisz parametry buforowania, pliki będą buforowane poprawnie, a serwer może zwrócić błąd 304 lub nową zawartość.

Tak właśnie należy to zrobić. Używanie losowych parametrów lub numeru wersji w adresach URL jest bardziej jak hack niż cokolwiek innego.

http://www.checkupdown.com/status/E304.html http://en.wikipedia.org/wiki/HTTP_ETag http://www.xpertdeveloper.com/2011/03/last-modified-header-vs- expire-header-vs-etag /

Po przeczytaniu zobaczyłem, że jest także data ważności. Jeśli masz problem, być może masz ustawiony termin ważności. Innymi słowy, kiedy przeglądarka zbuforuje twój plik, ponieważ ma on datę ważności, nie powinien być zmuszony żądać go ponownie przed tą datą. Innymi słowy, nigdy nie poprosi pliku na serwer i nigdy nie otrzyma 304 niezmodyfikowanego. Będzie po prostu używał pamięci podręcznej, aż do osiągnięcia daty ważności lub wyczyszczenia pamięci podręcznej.

Zgaduję, że masz jakiś termin ważności i powinieneś użyć ostatnio zmodyfikowanych etagów lub ich kombinacji i upewnić się, że nie ma daty wygaśnięcia.

Jeśli ludzie często odświeżają się, a plik nie jest często zmieniany, rozsądnie jest ustawić dużą datę ważności.

Moje 2 centy!

Loïc Faure-Lacroix
źródło
1

Wdrożyłem to proste rozwiązanie, które działa dla mnie (jeszcze nie w środowisku produkcyjnym):

function verificarNovaVersio() {
    var sVersio = localStorage['gcf_versio'+ location.pathname] || 'v00.0.0000';
    $.ajax({
        url: "./versio.txt"
        , dataType: 'text'
        , cache: false
        , contentType: false
        , processData: false
        , type: 'post'
     }).done(function(sVersioFitxer) {
        console.log('Versió App: '+ sVersioFitxer +', Versió Caché: '+ sVersio);
        if (sVersio < (sVersioFitxer || 'v00.0.0000')) {
            localStorage['gcf_versio'+ location.pathname] = sVersioFitxer;
            location.reload(true);
        }
    });
}

Mam mały plik, w którym znajdują się pliki HTML:

„versio.txt”:

v00.5.0014

Ta funkcja jest wywoływana na wszystkich moich stronach, więc podczas ładowania sprawdza, czy wartość wersji localStorage jest niższa niż bieżąca wersja i wykonuje

location.reload(true);

... aby wymusić przeładowanie z serwera zamiast z pamięci podręcznej.

(oczywiście zamiast localStorage możesz używać plików cookie lub innego trwałego miejsca do przechowywania klientów)

Wybrałem to rozwiązanie ze względu na jego prostotę, ponieważ zachowanie tylko jednego pliku „versio.txt” wymusi ponowne załadowanie całej witryny.

Metoda queryString jest trudna do wdrożenia i jest również buforowana (jeśli zmienisz z wersji 1.1 na poprzednią wersję, ładuje się z pamięci podręcznej, oznacza to, że pamięć podręczna nie jest opróżniana, utrzymując wszystkie poprzednie wersje w pamięci podręcznej).

Jestem trochę nowicjuszem i doceniam twoje profesjonalne sprawdzenie i sprawdzenie, aby upewnić się, że moja metoda jest dobrym podejściem.

Mam nadzieję, że to pomoże.

Seak
źródło
0

Istnieje jedna sztuczka, której można użyć: sztuczka polega na dodaniu parametru / łańcucha do nazwy pliku w znaczniku skryptu i zmianie go podczas zmiany pliku.

<script src="myfile.js?version=1.0.0"></script>

Przeglądarka interpretuje cały ciąg jako ścieżkę do pliku, mimo że co następuje po „?” są parametrami. Więc wat dzieje się teraz, gdy następnym razem, gdy zaktualizujesz plik, po prostu zmień numer w tagu skryptu na swojej stronie internetowej (przykład <script src="myfile.js?version=1.0.1"></script>), a każda przeglądarka użytkowników zobaczy plik zmienił się i weź nową kopię.

Joish
źródło
0

Czy zmusić przeglądarki do wyczyszczenia pamięci podręcznej lub ponownego załadowania poprawnych danych?Wypróbowałem większość rozwiązań opisanych w stackoverflow, niektóre działają, ale po pewnym czasie ostatecznie buforuje i wyświetla poprzednio załadowany skrypt lub plik. Czy istnieje inny sposób, który wyczyści pamięć podręczną (css, js itp.) I faktycznie działa we wszystkich przeglądarkach?

Do tej pory stwierdziłem, że określone zasoby mogą być ponownie ładowane indywidualnie, jeśli zmienisz datę i godzinę w swoich plikach na serwerze. „Czyszczenie pamięci podręcznej” nie jest tak łatwe, jak powinno być. Zamiast wyczyścić pamięć podręczną w moich przeglądarkach, zdałem sobie sprawę, że „dotknięcie” buforowanych plików serwera faktycznie zmieni datę i godzinę pliku źródłowego buforowanego na serwerze (testowane na Edge, Chrome i Firefox) i większość przeglądarek automatycznie pobierze najwięcej aktualna świeża kopia zawartości serwera (kod, grafika i multimedia). Sugeruję po prostu skopiowanie najbardziej aktualnych skryptów na serwerze i rozwiązanie „wykonaj czynności dotykowe” przed uruchomieniem programu, aby zmienił datę wszystkich plików powodujących problemy na najbardziej aktualną datę i godzinę, a następnie pobierze nową kopię do przeglądarki:

<?php
   touch('/www/sample/file1.css');
   touch('/www/sample/file2.js');
?>

potem ... reszta twojego programu ...

Zajęło mi trochę czasu, aby rozwiązać ten problem (ponieważ wiele przeglądarek zachowuje się inaczej w stosunku do różnych poleceń, ale wszystkie sprawdzają czas plików i porównują z pobraną kopią w przeglądarce, jeśli inna data i godzina przeprowadzą odświeżenie), jeśli nie może pójść we właściwy sposób, zawsze istnieje inne przydatne i lepsze rozwiązanie. Pozdrawiam i wesołego biwakowania. Przy okazji touch (); lub alternatywy działają w wielu językach programowania, w tym w javascript bash sh php, i można je włączyć lub wywołać w formacie HTML.

Luis H Cabrejo
źródło
1
jeśli plik zostanie zmodyfikowany, znacznik czasu i tak jest już zmieniony, więc wymuszenie go ponownie nie przynosi korzyści.
Fusca Software
Polecenie dotykowe w ogóle nie zmienia pliku. Zmienia atrybut daty i godziny, konwertując go do nowszej wersji, oszukując przeglądarkę i pobierając ją jako nową kopię.
Luis H Cabrejo
-1

Czy chcesz wyczyścić pamięć podręczną, czy po prostu upewnij się, że bieżąca (zmieniona?) Strona nie jest buforowana?

Jeśli to drugie, powinno być tak proste jak

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
Tim Crone
źródło
Niedawno przeczytałem o tym podejściu w poście o Chrome i znalazłem spójne wyniki tylko na kilku serwerach na żywo, localhost i plikach Windows ... z Firefox 3.6.
Danjah