Caching, Meta-Tags und www.grindelsneak.de

[st]

Ich quake vor Langeweile jetzt einfach mal dazwischen:

der Umstand, dass ich die ganzen Seiten in Zusammenhang mit Tippreport und Co. immer extra refreshen muss... Könnte man da nicht mal das Caching deaktivieren? Also ein <meta http-equiv="Cache-Control" content="no-cache" /> würde schon helfen, denke ich...

Wenn Dein Browser bei Objekten, die kein explizites oder, wie im Fall des Tippreports, ein unkorrektes Verfallsdatum haben, die Gültigkeit seines Caches nicht bei jedem Aufruf prüft, dann ist das kein Fehler des Servers, und somit ist er auch nicht auf Serverseite zu beheben.
Hast Du an den Einstellungen gefummelt? Oder benutzt Du den Internet Explorer? ;>

Mit einer Cache-Control-Anweisung wird's unter diesen Voraussetzungen nur verschlimmbessert.

Bei mir funktioniert's jedenfalls einwandfrei. Der Browser fragt bei jedem Abruf beim Server nach, ob sich die Seite seit dem letzten Mal geändert hat, und zeigt daher immer brav die aktuelle Version.

[Kai aus Reihe 9]

Moin!

Wenn Dein Browser bei Objekten, die [...] ein unkorrektes Verfallsdatum haben, die Gültigkeit seines Caches nicht bei jedem Aufruf prüft, dann ist das kein Fehler des Servers, und somit ist er auch nicht auf Serverseite zu beheben.

Jo, da hast Du nicht Unrecht. Zumindest nicht mit der ersten Aussage. Da ist in der Tat ein fehlerhaftes "expires" drin... Ein Fehler von Serverseite, wie Du wohl zugeben musst.

Warum ich meinen Mozilla deswegen fehlkonfigurieren soll, kannst Du mir aber auch nicht plausibel erklären, oder? Trotzdem danke für den Hinweis...

Bis dann
Kai

[st]

Da ist in der Tat ein fehlerhaftes "expires" drin... Ein Fehler von Serverseite, wie Du wohl zugeben musst.

Ja, aber der hat nichts mit Deinem Problem zu tun bzw. sollte ganz im Gegenteil genauso wie no-cache wirken. So wie ich das sehe, kann es nicht am Server liegen, aber was da nun möglicherweise noch alles im Hintergrund werkelt, weiß ich natürlich auch nicht.

Warum ich meinen Mozilla deswegen fehlkonfigurieren soll, kannst Du mir aber auch nicht plausibel erklären, oder?

Kann ich hellsehen? :) Es kommt aber im Grunde auch nur die Option in Frage, die es erlaubt, zwischen ständiger Prüfung, Prüfung nur einmal pro Browserstart und Prüfung nur nach Ablauf zu wählen (Erweitert -> Cache).

Mit Mozilla könntest Du http://livehttpheaders.mozdev.org/ drauf ansetzen - da sieht man zumindest genau, was der Browser wie beim Server anfragt.

[Kasi Mir]

Da ist in der Tat ein fehlerhaftes "expires" drin... Ein Fehler von Serverseite, wie Du wohl zugeben musst.

Ja, aber der hat nichts mit Deinem Problem zu tun bzw. sollte ganz im Gegenteil genauso wie no-cache wirken. So wie ich das sehe, kann es nicht am Server liegen, aber was da nun möglicherweise noch alles im Hintergrund werkelt, weiß ich natürlich auch nicht.

Ich bin ja kein Webdesigner und in diesem Bereich alles andere als Experte, aber: was genau ist bei den derzeitigen Webseiten eigentlich falsch an dem (fehlenden) Expires-Meta-Tag?

Nach etwas Recherche habe ich alle wesentlichen Seiten jetzt jedenfalls um

Code: Alles auswählen

<meta http-equiv="Expires" content="300">

ergänzt, was, soweit ich die Sache verstehe, Browser anweist, die Seite von grindelsneak.de neu zu laden, wenn die lokale Kopie mehr als fünf Minuten alt ist. Ist das richtig?

Gruß
Kasi Mir

[st]

Ich bin ja kein Webdesigner und in diesem Bereich alles andere als Experte, aber: was genau ist bei den derzeitigen Webseiten eigentlich falsch an dem (fehlenden) Expires-Meta-Tag?

Gefehlt hat da nichts, das, was da war (ist), war (ist) falsch, weil statt eines Datums nur eine Zahl auftauchte.

Nach etwas Recherche habe ich alle wesentlichen Seiten jetzt jedenfalls um

Code: Alles auswählen

<meta http-equiv="Expires" content="300">

ergänzt, was, soweit ich die Sache verstehe, Browser anweist, die Seite von grindelsneak.de neu zu laden, wenn die lokale Kopie mehr als fünf Minuten alt ist. Ist das richtig?

Wo immer Du recherchiert hast, recherchiere dort nie wieder :) In der einzig wahren Wahrheitsquelle, dem HTTP/1.1-Standard RFC 2616 (zum Beispiel beim W3C unter http://www.w3.org/Protocols/rfc2616/rfc ... l#sec14.21 ), steht bei Expires:

The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format:

Expires = "Expires" ":" HTTP-date

An example of its use is

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Also: Datum. Von Sekunden ist da nicht die Rede. Da hat wohl irgendwer irgendwann mal die Konfiguration seines Webservers mit HTTP verwechselt - und seitdem geistert das durchs Netz, weil jeder von jedem abschreibt, aber niemand vom richtigen ;>

Wie dem auch sei, ich vermute das Problem nach wie vor in der Reihe 10, ansonsten hätten andere sich auch schon gemeldet. Ich würde sogar ganz im Gegenteil das Ablaufdatum des Tippreports auf den jeweils nächsten Dienstag Morgen setzen. Einmal abgerufen, kann die Seite schließlich in den Caches bleiben, und ab Dienstag muss sie von ganz alleine jedesmal neu geprüft werden, weil sie abgelaufen ist.

Statt ständig am <meta>-Teil rumzufummeln, kannst Du auch eine Datei .htaccess in /sneaktip/ anlegen (ja, mit Punkt vorne, nein, der Windows-Texteditor mag das nicht, ja, es gibt andere Editoren, Proton zum Bleistift) und dort folgendes reinschreiben:

ExpiresActive on
ExpiresByType text/html "modification plus 6 days 12 hours"

Dann geht's automatisch, Verfallsdatum = Änderung der Datei plus angegebenen Zeitraum. Siehe http://httpd.apache.org/docs/mod/mod_expires.html .

[Kai aus Reihe 9]

Moin!

Uiii, stimmt, hier wollte ich auch immer noch mal was schreiben.

Erstmal, was ST da schreibt, stimmt alles so Jedoch dürfte der Fehler mit den Sekunden inzwischen von allen halbwegs akzeptablen Browsern interpretiert werden... Sei es falsch oder auch nicht. Wenn selbst selfhtml das kommentarlos zulässt *seufz*.

Ich hatte damals nur den letzten Tipreport angesehen (also der Woche damals) und hatte da dann den Meta-Tag gesehen. Und 'ne (zu) kurze Recherche ergab halt, dass der Tag mit dem genannten Datumsformat zu füllen sei. Daher nahm ich an, dass da der Fehler zu suchen sei. Mit *dem* Tipp-Report und allen folgenden hatte ich das Problem jedoch nicht mehr.

Wie man in der History aber nachverfolgen kann, war dieser Eintrag früher gar nicht gesetzt. Dass sich mein Browser trotzdem teils tagelang auf 'ne gecachte Version gestürzt hat, ist mir selber etwas unklar. Aber 'ne Browser-Session dauert bei mir eigentlich seltener ein paar Tage

Wie auch immer der Fehler entstand, natürlich hatte den nicht jeder. Nur gibt es ja die Funktionen bzgl. des Caches oder des Expire-Dates ja nicht zum Spass. Das von Server-Seite zu steuern, ist in vielen Fällen sinnvoll, wie z.B. beim Tippreport...

Bis dann
Kai

PS: Neulich vor "Vanity Fair" lief auch der Trailer von Star Wars III, ist in der Trailerinfo nicht enthalten

[st]

Jedoch dürfte der Fehler mit den Sekunden inzwischen von allen halbwegs akzeptablen Browsern interpretiert werden... Sei es falsch oder auch nicht. Wenn selbst selfhtml das kommentarlos zulässt *seufz*.

Auch die Götter sind fehlbar..

Nur gibt es ja die Funktionen bzgl. des Caches oder des Expire-Dates ja nicht zum Spass. Das von Server-Seite zu steuern, ist in vielen Fällen sinnvoll, wie z.B. beim Tippreport...

Ganz meine Meinung. Deshalb ja der Vorschlag mit dem Ablauf am jeweils nächsten Dienstag mir den erwähnten Vorteilen gegenüber einer Sekundenangabe. Ich finde, der Tippreport ist eigentlich sogar einer der seltenen Idealfälle.