Frage zu 'expires' und 'reload'
Robert Kuhlemann
- html
Hallo,
per meta-tag kann ich erzwingen, daß eine Webseite nicht vom Cache gelesen wird.
Format: ..http-equiv='expires' content='0'
Statt 0 kann ich hier auch ne andere Zahl (oder Datum) einsetzen.
Wenn ich mit ner Zahl, z.B. 5 arbeite, heißt das dann, daß die Webseite alle 5 Zeiteinheiten nachgelesen wird? Weiß das jemand genau?
Zusatzfrage:
Wirkt 'location.reload()' wie expires mit 0 oder lädt der ggfs. auch vom Cache?
MfG Robert Kuhlemann
Hi ...
Hallo,
per meta-tag kann ich erzwingen, daß eine Webseite nicht vom Cache gelesen wird.
Format: ..http-equiv='expires' content='0'
Statt 0 kann ich hier auch ne andere Zahl (oder Datum) einsetzen.
Wenn ich mit ner Zahl, z.B. 5 arbeite, heißt das dann, daß die Webseite alle 5 Zeiteinheiten nachgelesen wird? Weiß das jemand genau?
Was sind bei dir 5 Zeiteinheiten? ;-)
Das bedeutet das alle 5 Tage die Seite komplett neugeladen wird.
Zusatzfrage:
Wirkt 'location.reload()' wie expires mit 0 oder lädt der ggfs. auch vom Cache?
Der läd' die Seite kompeltt neu!
MfG Robert Kuhlemann
Gruß ... Simon
Hallo,
was verstehst Du unter komplett?
Meine Frage bezog sich auf das woher. Das kann die Originaladresse, aber auch der Cache auf dem PC oder in einem Proxy sein.
Die Zeiteinheit ist laut Selfhtml Sekunden.
Es ergeben sich also folgende berechtigte Fragen:
MfG Robert Kuhlemann
Hi ...
Hallo,
per meta-tag kann ich erzwingen, daß eine Webseite nicht vom Cache gelesen wird.
Format: ..http-equiv='expires' content='0'
Statt 0 kann ich hier auch ne andere Zahl (oder Datum) einsetzen.
Wenn ich mit ner Zahl, z.B. 5 arbeite, heißt das dann, daß die Webseite alle 5 Zeiteinheiten nachgelesen wird? Weiß das jemand genau?
Was sind bei dir 5 Zeiteinheiten? ;-)
Das bedeutet das alle 5 Tage die Seite komplett neugeladen wird.
Zusatzfrage:
Wirkt 'location.reload()' wie expires mit 0 oder lädt der ggfs. auch vom Cache?
Der läd' die Seite kompeltt neu!
MfG Robert Kuhlemann
Gruß ... Simon
Hi,
per meta-tag kann ich erzwingen, daß eine Webseite
nicht vom Cache gelesen wird.
Format: ..http-equiv='expires' content='0'
hm, ja, in HTTP/1.0 war das so.
In HTTP/1.1 gibt es diesen Header noch, aber nachrangig gegenüber "Cache-Control".
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
Statt 0 kann ich hier auch ne andere Zahl (oder
Datum) einsetzen.
Eigentlich solltest Du nur ein Datum einsetzen können.
Und zwar ein Datum gemäß RFC 1123.
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)
Daß einige Browser gnädigerweise auch illegale Angaben wie '0' tolerieren, ist deren Privatvergnügen, meines Wissens aber kein gültiger Standard.
Relative Sekundenangaben zu erzeugen ist natürlich für den Seitenverfasser einfacher als absolute Datumswerte.
(Mit denen hättest Du via <meta> automatisch verloren - normalerweise erzeugt man HTTP-Header halt auch im HTTP-Server und nicht im Dokument.)
"Cache-Control:" hat dann diese Idee der relativen Sekundenangabe (und zwar bezogen auf den Auslieferungszeitpunkt) zum Standard erhoben.
Das wiederum verstehen halt nur HTTP/1.1-kompatible Clients (und vor allem auch nur solche Proxy-Server).
Insofern strebe ich selbst die Strategie an, sowohl "Cache-Control:" als auch "Expires:" zu senden, um alle Leute glücklich zu machen.
Wenn ich mit ner Zahl, z.B. 5 arbeite, heißt das
dann, daß die Webseite alle 5 Zeiteinheiten
nachgelesen wird?
Es bedeutet, daß der Server dem Client garantiert, daß der Inhalt dieses Dokument für die angegebene Zeitspanne auf dem Server konstant sein wird.
Es ist eine Aufforderung an den Client, sich diese Information zunutze zu machen, um ein intelligentes Caching-Verfahren zu realisieren und die Anzahl seiner Anforderungen an den Server in Grenzen zu halten.
Mehr als diese Aufforderung steht dem Server nicht zu, wenn er Caching _erlauben_ will. _Verbieten_ dagegen kann er es aktiv (mit denselben Headern, aber anderen Werten darin).
Im einfachsten aller Fälle holt der Client das Dokument vom Server bei jeder Verwendung dieses Dokuments.
Besitzt er jedoch einen Cache, dann stellt sich die Frage, wann er diesem Cache glauben (also dessen Inhalt benutzen) darf und wann nicht.
HTTP erlaubt dem Client, den Server mit einem "conditional GET" nach einer Seite zu fragen: "Hallo Server, ich will die Seite X haben, von der ich aber die Version des Zeitpunktes T bereits besitze." Der Server antwortet dann entweder mit dem Inhalt der Seite X oder mit dem HTTP-Status 304 "Du darfst Deinen Cache-Inhalt weiterhin verwenden".
Letzteres ist natürlich bei großen Seiten schon ein erheblicher Fortschritt, verglichen der Übertragung der gesamten Seite. Deshalb hat sich dieses Verfahren bei den Browsern allgemein durchgesetzt.
Andererseits hat sich dabei nicht die Anzahl der Requests, sondern nur deren mittlere Größe geändert.
Die "Expires:"-Angabe hingegen erlaubt dem Client, zuallererst einmal zu prüfen, ob er überhaupt fragen muß! Nur wenn das Haltbarkeitsdatum der Seite verfallen ist, braucht er noch einen Request an den Server zu senden. Und das kann dann immer noch ein "conditional GET" sein - denn der Server könnte ja eine "vorsichtige" Haltbarkeitsdauer gesendet haben, beispielsweise eine Stunde, während das Dokument seinen Inhalt über Wochen hinweg nicht ändert.
Von den modernen Browsern glaube ich behaupten zu dürfen, daß sie alle im Modus "automatic" die über "Expires:" angegebenen Aufbewahrungsfristen glauben und ansonsten in vielen Fällen "conditional GET" machen - sofern man keinen Request zum Server erzwingt.
Der Client darf kein "Expires:"-Datum raten. Wenn dieses Datum abgelaufen ist, muß er sicherheitshalber den Server fragen. Aber die meisten mir bekannten Server scheinen keine "Expires:"-Header zu senden - dazu müßte nämlich jemand konfigurieren, was genau gesendet werden soll. (Ich bin gerade dabei, genau dies zu tun.) Die entsprechenden Orgien von "conditional GET" in den Logfiles sind das Ergebnis der Browser-Tätigkeit.
Anders sieht es beispielsweise mit Proxy-Servern aus. Deren Aufgabe ist es, Seiten weiter zu vermitteln. Wenn der Betreiber eines Proxy-Servers Performance vor Aktualität setzt, kann er versuchen, "Expires:"-Daten zu raten. In dem Proxy-Server, den ich hier im Büro verwende, kann man beispielsweise konfigurieren, daß er sich ein wahrscheinliches Gültigkeitsintervall aus dem Intervall zwischen "jetzt" und dem Entstehungsdatum des Dokuments "ausrechnet" - nach der Methode: "Diese Seite hat sich jetzt schon so viele Wochen lang nicht geändert, da frage ich in den nächsten 6 Stunden auch nicht mehr extra nach, weil ich den Traffic zu diesem Server in Grenzen halten will". Selbiges kann man im Proxy sehr detailliert spezifizieren - beispielsweise unterschiedliche Caching-Prozeduren für HTML-Dokumente, GIFs, CSS, JavaScript und tausend andere Dinge.
Verglichen mit den vollen Möglichkeiten von HTTP ist <meta http-equiv="..."> nur ein _sehr_ schwacher Abklatsch der Realität.
Wenn Dich so etwas wirklich interessiert, solltest Du Dich in die Konfiguration des Webservers selbst einlesen. Denn dessen Job ist das eigentlich, was Du da gerade dem HTML-Dokument aufbürdest.
Wirkt 'location.reload()' wie expires mit 0 oder
lädt der ggfs. auch vom Cache?
Eine explizite Reload-Anforderung durch den Benutzer (!) überschreibt nach meiner Erfahrung alle HTTP-Header. Letzten Endes ist es immer noch der Benutzer, der das Neu-Laden der Seite im Client erzwingen kann - beispielsweise weil sein Cache-Inhalt kaputt gegangen ist (Darstellungsfehler auf dem Bildschirm etc.).
Wie genau man eine solche Reload-Anforderung erzwingen kann (beim M$IE z. B. mit Cntrl-F5) und wie genau die JavaScript-Implementierung von "location.reload()" ist, wirst Du vermutlich ausprobieren müssen.
(Nimm Dir einen lokalen Webserver und beobachte dessen access_log - dann siehst Du, wann welcher Browser Requests sendet, und über den HTTP-Statuscode des Servers eventuell auch, welche Requests das waren.)
Viele Grüße
Michael
Danke!
Das muß ich erstmal alles verdauen!
MfG Robert