hallo http-Experten!
Kann mir bitte mal jemand mein Hirn entknoten? In einem Intranet liefert
ein Server dynamische Seiten mit Links auf statische Dateien. Diese darf
ein Browser gerne cachen, aber irgendwann werden sie doch mal
aktualisiert und dann gibt es Tränen. Der Server liefert auf ein HEAD
hin z.B.
1
Date: Wed, 17 Feb 2021 09:15:46 GMT
2
Content-Length: 64657
3
Content-Type: application/pdf
4
Last-Modified: Wed, 17 Feb 2021 06:31:32 GMT
5
Client-Date: Wed, 17 Feb 2021 09:15:46 GMT
also dürfte der Browser nicht seine Kopie von vorgestern anzeigen, oder?
Ein Expires gibt es natürlich nicht, solche Dateien werden evt. nie
geändert.
Wahrscheinlich irrelevant, obwohl es jetzt zum 2. Mal beklagt wurde: Die
Datei ist auf 2 Wegen erreichbar, also 2 verschiedene Links auf die
gleiche Datei. Angeblich bekommt man mit dem einen Link die alte, mit
dem anderen die neue Datei.
Hallo
wie lautet noch mal die Frage?
Auch in einen Fachforum sollte die Frage etwas allgemeinverständlicher
sein - oder zumindest erklärt werden was den mit all den sehr
Fachspezifischen Erläuterungen gemeint ist.
Habe eigentlich bei den Titel auf eine Interessante Frage mit
entsprechender Diskussion verschiedenster Meinungen gehofft, aber so...
Schade.
Ich hab mal gelesen, dass man sich auf ein Neuladen nie verlassen kann,
auch nicht mit der no-cache -Anweisung im html. Eine effektive Methode
sind eindeutige Namen, wenn sich der Dateinamen aendert, laedt der
Browser immer nach.
Bauform B. schrieb:> Der Server liefert auf ein HEAD> hin
Ist dem Browser egal. Wenn der seine Ursprungs-Kopie mit "Expires:
never" Header bekommen hat und die so im Cache liegt, dann fragt er auch
nicht per HEAD beim Server nach ob's evtl. doch was neues gibt.
Insofern: Zeig lieber die Headers, die dein Server beim "GET"-Reply
mitsendet.
Praktiker schrieb:> Habe eigentlich bei den Titel auf eine Interessante Frage mit> entsprechender Diskussion verschiedenster Meinungen gehofft, aber so...
Das tut mir leid, ehrlich. Mir ist einfach kein Betreff eingefallen, ein
Versuch war z.B. "[http] no-cache - oder doch nicht?". Aber gerade in
diesem Forum bekommst du wahrscheinlich die Diskussion passend zum
Betreff ;)
100Ω W. schrieb:> Beim Firefox zumindest (Chrome und Edge weiß ich nicht) kann man Strg+F5> drücken um die Seite komplett neu zu laden.
Oder CTRL-R oder... Aber das ist eine Notlösung, normal kommt man doch
garnicht auf die Idee, dass alte Daten angezeigt werden.
Cache löschen bei beenden. Das sollte in 80& der Fälle ausreichen.
Davon abgesehen selbst bei der Postbank habe ich das Problem das die
Konto-Seite nicht aktualisiert wird, nach einer Überweisung.
Bei Windows reicht die Standard-Taste F5 (Weil die bei Windows für fast
alles) ein ReLoad durchzuführen.
"Don't do that then" ist darauf schon seit langem die passende Antwort.
;-)
Erst mal zum Prinzip des Cachings: ein Browser macht da keinen HEAD
Request, sondern ein GET mit passenden Optionen, bei denen ein Datum
oder ETag mitgeliefert wird und der Server dann freundlich mit einem 304
(not modified) antworten kann.
Der Broswer schickt natürlich nur einen Request wenn der Content noch
nicht "stale" ist. Wenn man vom Server her da kein Expire mitschickt
baut der Browser nach einer Heuristik selbst was zusammen - schlecht
nachvollziehbar. Also besser selbst einen Expire-Header mit geeigneter
Zeit mitschicken.
ETag ist da auch schon das passende Stichwort: bring deinem Server bei,
bei statischem Content ein ETag mitzuschicken, dann wird ein halbwegs
moderner Browser dem Server dieses beim Request mitschicken. Ist die
Datei geändert worden, dann schickt er den Content, ansonsten eben einen
304.
Alternativ wird das Prinzip der ewigen Ressourcen genutzt: man berechnet
einen Krypto-Hash der Daten und benennt die Datei dann passend. Damit
hängt der Name der Datei vom Inhalt ab und es kann mit dem Cache keine
Probleme mehr geben. Man muss jetzt "nur" dafür sorgen, das die richtige
Version der Datei referenziert wird (bei dynamisch generierten Seiten
eigentlich nicht schwer). Dieses Verfahren vermeidet sowohl
Verzögerungen bis geänderte Dateien sichtbar werden als auch unnötigen
Datentransfer (da freuen sich mobile User).
Ralf D. schrieb:> Alternativ wird das Prinzip der ewigen Ressourcen genutzt: man berechnet> einen Krypto-Hash der Daten und benennt die Datei dann passend.
Dieses gefällt mir, sowas gehört aus anderen Gründen sowieso gemacht,
dankeschön!
Mit VMS wäre das nicht passiert, da bekommt die Datei mit jeder Änderung
automatisch eine neue Versionsnummer, überschreiben geht nur mit Gewalt
;) Für die meisten Dateien müsste es eigentlich auch reichen, die mtime
in den Namen zu packen, mal sehen...
Ich biete bei uns Dokumente mit Get-Parameter an:
Achtung: ersetzte - durch < und >, sonst "Der Beitrag scheint Spam zu
enthalten"
1
-a href = "xyz.pdf?20210217"-Dokument XZY-/a-
Bei einer neuen Dokumentenversion wird der Parameter (20210217)
entsprechend dem Datum angepasst. Angeblich zwingt das die Browser, das
Dokument neu zu Laden, statt es aus dem Cache zu holen.
Ich habe mal Software für ein Gerät geschrieben, das seinen
Bildschirminhalt als BMP per Webserver zur Verfügung stellen kann (zur
Fernsteuerung). Natürlich will man nicht, daß jemals ein gecachetes Bild
angezeigt wird. Diese Header haben bei allen üblichen Browsern geholfen:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: -1
Sven schrieb:> Bei einer neuen Dokumentenversion wird der Parameter (20210217)> entsprechend dem Datum angepasst. Angeblich zwingt das die Browser, das> Dokument neu zu Laden, statt es aus dem Cache zu holen.
In der einen Richtung funktioniert der Trick, aber ich fürchte, dann
cached er es garnicht.
Tassilo H. schrieb:> Natürlich will man nicht, daß jemals ein gecachetes Bild> angezeigt wird.
Naja, das sind etwas andere Anforderungen. Auf einem Laptop, der per
GSM angebunden ist, weiß man den Cache zu schätzen ;) Besonders für z.B.
Datenblatt-PDFs, die sich doch eher selten ändern. Aber wenn sie sich
ändern...
Thread beobachten
Seitenaufteilung abschalten