nicht angemeldet
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Hallo!
Ich habe eine Seite in XHTML5 (mal wieder...) und jetzt wo ich sie online habe, habe ich festgestellt, dass die Layout-Grafiken beim durchklicken der Menüpunkte kurz verschwinden und, als ob sie neu geladen würden, wieder erscheinen.
Wie kann ich überprüfen ob die Dateien tatsächlich neu geladen werden, wie ich es vermute, oder aus dem Cache kommen?
Oder ist das normales Verhalten?
Kann man es verhindern?
Ich kenn mich nicht besonders mit den Angaben von Live HTTP Headers aus aber müsste ich nicht bei Dateien die im Cache liegen einen Status "not modified" bekommen?
Danke für eure Hilfe!
Uwe
Hi,
Wie kann ich überprüfen ob die Dateien tatsächlich neu geladen werden, wie ich es vermute, oder aus dem Cache kommen?
Firebug, Net-Panel
Ich kenn mich nicht besonders mit den Angaben von Live HTTP Headers aus aber müsste ich nicht bei Dateien die im Cache liegen einen Status "not modified" bekommen?
In erster Linie Statuscode 304. Ja, idR. lautet dessen „Begleittext“ “not modified”.
Oder ist das normales Verhalten?
Definiere „normal“ :-)
Kann man es verhindern?
Wenn man ein bestimmtest Caching-Verhalten wünscht, macht man natürlich beim Ausliefern der Ressource auch entsprechende Angaben in den HTTP Response Headern.
MfG ChrisB
Hallo!
Wenn man ein bestimmtest Caching-Verhalten wünscht, macht man natürlich beim Ausliefern der Ressource auch entsprechende Angaben in den HTTP Response Headern.
Danke euch beiden erstmal! Soweit hab ich das auch alles verstanden aber wie bringe ich den entsprechenden Header unter? In z.B. einer HTML4- oder XHTML-Datei schickt man ja auch keinen entsprechenden Header extra. Von daher irritiert mich das Verhalten hier ein wenig. Oder liegt es an der .htaccess die ich dort jetzt einsetze?
Der Inhalt ist einfach nur
AddType application/xhtml+xml .html
Uwe
Hi,
aber wie bringe ich den entsprechenden Header unter?
In dem du den Server entsprechend konfigurierst, diese Header zu senden.
In z.B. einer HTML4- oder XHTML-Datei schickt man ja auch keinen entsprechenden Header extra.
Eben, da kümmert sich der Webserver drum.
Oder liegt es an der .htaccess die ich dort jetzt einsetze?
Der Inhalt ist einfach nur
AddType application/xhtml+xml .html
Wenn nicht schon in der zentralen Serverkonfiguration dafür gesorgt ist, dass entsprechende Header für die jeweiligen Dateitypen zugewiesen werden, und von dir auch keine ergänzend gesetzt werden – dann sendet der Server im Zweifelsfalle gar keine. (Ebenfalls per Firebug leicht überprüfbar.)
MfG ChrisB
In dem du den Server entsprechend konfigurierst, diese Header zu senden.
Da sind wir wieder dabei, dass der Server nur gemietet ist. Oder geht es auch per .htaccess?
Wenn nicht schon in der zentralen Serverkonfiguration dafür gesorgt ist, dass entsprechende Header für die jeweiligen Dateitypen zugewiesen werden, und von dir auch keine ergänzend gesetzt werden – dann sendet der Server im Zweifelsfalle gar keine. (Ebenfalls per Firebug leicht überprüfbar.)
Live HTTP headers sagt bei jedem Aufruf Status-Code 200.
Womit müsste ich denn die .htaccess ergänzen damit das Verhalten dem von (X)HTML entspricht?
Firebug hab ich zwar installiert, aber wo finde ich denn da die übermittelten header?
Uwe
Hi,
Da sind wir wieder dabei, dass der Server nur gemietet ist. Oder geht es auch per .htaccess?
Da sind wir (wieder) an der Stelle, wo du dich vielleicht mal ein bisschen selber informieren könntest.
Wenn nicht schon in der zentralen Serverkonfiguration dafür gesorgt ist, dass entsprechende Header für die jeweiligen Dateitypen zugewiesen werden, und von dir auch keine ergänzend gesetzt werden – dann sendet der Server im Zweifelsfalle gar keine. (Ebenfalls per Firebug leicht überprüfbar.)
Live HTTP headers sagt bei jedem Aufruf Status-Code 200.
Ein HTTP Response besteht aus mehr als nur einem Statuscode.
Firebug hab ich zwar installiert, aber wo finde ich denn da die übermittelten header?
Noch mal: Net-Panel, auf Deutsch vermutlich „Netzwerk“-Tab.
MfG ChrisB
Da sind wir (wieder) an der Stelle, wo du dich vielleicht mal ein bisschen selber informieren könntest.
Wenn du mir sagst wo und nach welchen Stichpunkten ich ausschau halten soll gern. Nur mit dem Hinweis "informier dich selbst" kann ich beim besten Willen wenig anfangen.
Ein HTTP Response besteht aus mehr als nur einem Statuscode.
Was wäre denn da relevant? Wie gesagt sagt mir das nicht viel. Ansonsten waren wir ja schon bei "If-Modified-Since".
Noch mal: Net-Panel, auf Deutsch vermutlich „Netzwerk“-Tab.
Nochmal: Was wäre denn da relevant?
Ich seh dort aber gerade, dass ich bei einem Seiten-Refresh Status 304 bekomme, wenn ich die Seite aber per Link oder URL (Adresszeile) aufrufe bekomme ich immer Status 200.
Wie setze ich also den "If-Modified-Since"-header nicht nur beim Refresh? Und wieso wird er überhaupt beim Refresh aber nicht bei Aufruf per Link oder URL gesetzt?
Uwe
Hi,
Da sind wir (wieder) an der Stelle, wo du dich vielleicht mal ein bisschen selber informieren könntest.
Wenn du mir sagst wo und nach welchen Stichpunkten ich ausschau halten soll gern.
Fang doch einfach mal mit dem Google-Stichwort „HTTP Caching“ an.
MfG ChrisB
Hallo Uwe,
Ein HTTP Response besteht aus mehr als nur einem Statuscode.
Was wäre denn da relevant?
beispielsweise "Expires" oder "Cache-Control", evtl. auch "ETag". Ohne Anspruch auf Vollständigkeit.
Wie gesagt sagt mir das nicht viel. Ansonsten waren wir ja schon bei "If-Modified-Since".
Ja. Der gehört aber in den Request.
Ich seh dort aber gerade, dass ich bei einem Seiten-Refresh Status 304 bekomme, wenn ich die Seite aber per Link oder URL (Adresszeile) aufrufe bekomme ich immer Status 200.
Wie setze ich also den "If-Modified-Since"-header nicht nur beim Refresh?
Üblicherweise per Browserkonfiguration. Im Opera beispielsweise über Extras/Einstellungen/Erweitert, hier die Kategorie "Verlauf" auswählen und Haken bei "Webseiten prüfen" und "Bilder prüfen" setzen. Im IE hieß das früher "Neue Versionen der gespeicherten Seiten suchen", und die bevorzugte Auswahl wäre "(o) Bei jedem Zugriff" Im FF finde ich eine entsprechende Einstellung gerade nicht.
Und wieso wird er überhaupt beim Refresh aber nicht bei Aufruf per Link oder URL gesetzt?
Gute Frage. Finde ich auch nicht logisch.
Logisch fände ich es genau umgekehrt, denn beim Refresh will ich ja ausdrücklich "neu laden" oder "aktualisieren", also möchte ich auf jeden Fall den neuesten Stand der beteiligten Ressourcen.
Ciao,
Martin
Hallo Martin!
Üblicherweise per Browserkonfiguration. Im Opera beispielsweise über Extras/Einstellungen/Erweitert, hier die Kategorie "Verlauf" auswählen und Haken bei "Webseiten prüfen" und "Bilder prüfen" setzen. Im IE hieß das früher "Neue Versionen der gespeicherten Seiten suchen", und die bevorzugte Auswahl wäre "(o) Bei jedem Zugriff" Im FF finde ich eine entsprechende Einstellung gerade nicht.
Bitte nicht falsch verstehen aber wenn die Antwortenden "die entsprechende Einstellung gerade nicht [finden]", wie soll mir das als Fragender dann weiter helfen? Unter Extras->Einstellungen->Erweitert->Netzwerk-Tab steht etwas in der Richtung. Mehr konnte ich nicht finden.
Zum anderen würde eine solche Einstellung ja alle Seiten betreffen und wie gesagt "funktioniert" es ja bei (X)HTML, nur bei der (X)HTML5-Datei ist mir dieses Verhalten aufgefallen. Ausserdem hätte ich dafür nicht die entsprechende Einstellung ändern müssen damit das Problem plötzlich auftritt?
Gute Frage. Finde ich auch nicht logisch.
Logisch fände ich es genau umgekehrt, denn beim Refresh will ich ja ausdrücklich "neu laden" oder "aktualisieren", also möchte ich auf jeden Fall den neuesten Stand der beteiligten Ressourcen.
Schön, jetzt bin ich wenigstens nicht mehr der einzige der sich darüber wundert :)
Ansonsten belese ich mich mal, wie von ChrisB vorgeschlagen, zum Thema http caching und hoffe auf Erleuchtung. Noch seh ich aber nur schwarz.
Uwe
Mir ist aufgefallen, dass Opera nicht dieses Verhalten zeigt.
Ich kann zumindest nicht erkennen, dass irgendwelche Grafiken kurz verschwinden.
Mein anderes Problem im Hinterkopf überlege ich jetzt ob der aktuelle FF nicht einfach "zu dämlich" für XML ist bzw. ob meine Probleme überhaupt meine Probleme sind oder nicht doch die vom Firefox.
Vielleicht sollte ich die beiden Probleme also einfach ignorieren?
Uwe
Ansonsten belese ich mich mal, wie von ChrisB vorgeschlagen, zum Thema http caching und hoffe auf Erleuchtung. Noch seh ich aber nur schwarz.
Ich rate Dir zu folgendem Vorgehen:
Am besten fängst Du damit an, die vom SERVER gelieferten Header-Zeilen bei Dateien mit dem gewünschten Caching mit jenen zu vergleichen, welche nicht gecached werden zu vergleichen.
Ich empfehle dazu nicht einen Browser zu verwenden, bei dem womöglich an der Konfiguration gespielt wurde, sondern etwas neutrales wie netcat oder das etwas speziellere wget.
Diese header vergleicht Du und liest nach, was diese bewirken (sollen).
Dann wirst Du in der Hilfe zur Konfiguration Deines Webservers nachlesen, wie Du für bestimmte Dateien bestimmte Header sendest. Für den Apache wäre mod_header die <Files> oder <FilesMatch>- Direktive (darunter) interessant.
Was Dein Browser sendet ist im Übrigen auf Grund dessen konkreter, womöglich nicht besonders sinnvoller Konfiguration nicht so besonders interessant, bestimmte Effekte könnten nur bei Dir auftreten.
Hallo,
Ansonsten belese ich mich mal, wie von ChrisB vorgeschlagen, zum Thema http caching und hoffe auf Erleuchtung. Noch seh ich aber nur schwarz.
Ich rate Dir zu folgendem Vorgehen:
Am besten fängst Du damit an, die vom SERVER gelieferten Header-Zeilen bei Dateien mit dem gewünschten Caching mit jenen zu vergleichen, welche nicht gecached werden zu vergleichen.
soweit stimme ich zu, das trifft dann wohl den Knackpunkt.
Ich empfehle dazu nicht einen Browser zu verwenden, bei dem womöglich an der Konfiguration gespielt wurde, sondern etwas neutrales wie netcat oder das etwas speziellere wget.
Grundsätzlich eine gute Idee, das Problem zu isolieren - hier aber nicht zielführend, da die Reaktion des Servers und die HTTP-Header, die er generiert, teilweise stark vom konkreten Request abhängig sind.
Ich halte es daher für schlauer, die zugehörigen Request/Response-Paare zu betrachten, gern auch mit verschiedenen Clients. Firefox hat mit LiveHTTP dafür sein eigenes Werkzeug; bei Browsern, die nichts Vergleichbares mitbringen, hilft die Universalwaffe Wireshark. Auch ein protokollierender, transparenter HTTP-Proxy kann da hilfreich sein.
Diese header vergleicht Du und liest nach, was diese bewirken (sollen).
Genau. Und das setzt man dann in Beziehung mit den Effekten, die man bei den diversen Browsern beobachtet.
Was Dein Browser sendet ist im Übrigen auf Grund dessen konkreter, womöglich nicht besonders sinnvoller Konfiguration nicht so besonders interessant, bestimmte Effekte könnten nur bei Dir auftreten.
Ja, das ist genau der Grund, warum ich deinen Ansatz beispielsweise mit wget nicht für günstig halte. Er ist IMO zu weit vom realen Fall entfernt.
So long,
Martin
Hallo Martin!
Irgendwie komm ich langsam an die Grenzen meines Veständnisses.
Ich wollte doch nur eine Internetseite und nun hab ich einen Thread voll mit Fachbegriffen und Servergeschichten von denen ich zum ersten mal was höre.
So langsam verlässt mich die Motivation und ich überlege es einfach sein zu lassen und weiter in XHTML zu schreiben wenn sich mit XHTML5 solche Probleme auftun (an den Servereinstellungen schrauben damit es läuft) :(
Uwe
Hallo Fred!
Ich empfehle dazu nicht einen Browser zu verwenden, bei dem womöglich an der Konfiguration gespielt wurde, sondern etwas neutrales wie netcat oder das etwas speziellere wget.
Ich habe noch nie damit gearbeitet. Meine Schritte nach Anleitung in der beiliegenden readme.txt
1. Eingabeaufforderung -> und nc.exe -v www.example.tld 80
2. Ergebnis:
DNS fwd/rev mismatch: www.example.tld != sub.hoster.tld
www.example.tld [xxx.xxx.xxx.xxx] 80 (http) open
3. GET / HTTP/1.0
4. Ergebnis:
HTTP/1.1 302 found
Date: Fri, 04 Nov 2011 16:03:22 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch16
mod_ssl/2.2.3 OpenSSL/0.9.8c
X-Powered-By: PHP/5.2.0-8+etch16
Location: ./user/index.php
Content-Length: 0
Connection: close
Content-Type: text/html
War das so richtig? Ich vermute nicht. :(
Diese header vergleicht Du und liest nach, was diese bewirken (sollen).
Da dort mMn nichts steht was auch nur annähernd mit meinen Dateien zu tun hat... Wie gesagt, ich habe noch nie mit netcat gearbeitet...
Dann wirst Du in der Hilfe zur Konfiguration Deines Webservers nachlesen, wie Du für bestimmte Dateien bestimmte Header sendest. Für den Apache wäre mod_header die <Files> oder <FilesMatch>- Direktive (darunter) interessant.
Ok, ich pack das auf den Stapel "zu lesen", danke!
Uwe
Hi,
[...] Im FF finde ich eine entsprechende Einstellung gerade nicht.
Bitte nicht falsch verstehen aber wenn die Antwortenden "die entsprechende Einstellung gerade nicht [finden]", wie soll mir das als Fragender dann weiter helfen?
ich habe dir anhand von zwei anderen Browsern gezeigt, wie eine entsprechende Einstellung heißen könnte und in welchem Kontext sie realistischerweise zu finden ist. Man möge mir nachsehen, dass ich Firefox nur in Ausnahmefällen benutze, wo's unbedingt sein muss.
Unter Extras->Einstellungen->Erweitert->Netzwerk-Tab steht etwas in der Richtung.
Da kann ich die Größe des Cache-Speichers einstellen, aber nicht die Strategie.
Allerdings habe ich auf Wunsch eines einzelnen Herrn (*g*) nochmal in meiner Firefox-Konfiguration gewühlt, und beim Überfliegen der Einstellungen in about:config habe ich mich erinnert, dass ich wegen genau demselben Problem (FF nimmt Ressourcen aus dem Cache, obwohl neuere auf dem Server verfügbar wären) vor langer Zeit mal browser.cache.check_doc_frequency auf 1 gesetzt habe. Mir hat das damals geholfen.
Zum anderen würde eine solche Einstellung ja alle Seiten betreffen und wie gesagt "funktioniert" es ja bei (X)HTML, nur bei der (X)HTML5-Datei ist mir dieses Verhalten aufgefallen.
Und du hast immer noch nicht verglichen, worin sich die entsprechenden HTTP-Response-Header unterscheiden?
Ausserdem hätte ich dafür nicht die entsprechende Einstellung ändern müssen damit das Problem plötzlich auftritt?
Nein, nicht zwangsweise. Bisher hast du deine Dokumente nicht als application/xhtml+xml ausgeliefert, oder?
Ansonsten belese ich mich mal, wie von ChrisB vorgeschlagen, zum Thema http caching und hoffe auf Erleuchtung. Noch seh ich aber nur schwarz.
Das gibt sich. Es ist fast immer so, dass die Wege in der EDV steinig und mühsam sind. Aber wenn man dann schließlich am Ziel ist, war's doch irgendwie spannend und gibt einem ein Erfolgserlebnis.
Ciao,
Martin
Allerdings habe ich auf Wunsch eines einzelnen Herrn (*g*) nochmal in meiner Firefox-Konfiguration gewühlt, und beim Überfliegen der Einstellungen in about:config habe ich mich erinnert, dass ich wegen genau demselben Problem (FF nimmt Ressourcen aus dem Cache, obwohl neuere auf dem Server verfügbar wären) vor langer Zeit mal browser.cache.check_doc_frequency auf 1 gesetzt habe. Mir hat das damals geholfen.
Bei about:config habe ich noch nie etwas getan weil ich schlicht keine Ahnung davon habe. Kommt auch auf den Stapel "zu lesen".
Und du hast immer noch nicht verglichen, worin sich die entsprechenden HTTP-Response-Header unterscheiden?
Ich dachte ich solle das mit netcat tun? ôO
Und was genau soll ich denn vergleichen? Sorry aber ich habe wohl ein ganzes Sägewerk vor dem Kopf. Den "ersten" Aufruf einer Seite (da ist ja logischerweise immer Status 200) oder nach einem refresh oder einfach URL neu eingeben? Und womit soll ich vergleichen? Mit den ganzen möglichen headern? Reicht es nicht wenn ich sage ich bekomme Status 200 will aber 304?
Nein, nicht zwangsweise. Bisher hast du deine Dokumente nicht als application/xhtml+xml ausgeliefert, oder?
Mir war nicht klar, dass das einen Unterschied macht.
Das gibt sich. Es ist fast immer so, dass die Wege in der EDV steinig und mühsam sind. Aber wenn man dann schließlich am Ziel ist, war's doch irgendwie spannend und gibt einem ein Erfolgserlebnis.
Nach dem steinigen Weg kommt man aber oft mit gestauchten Gelenken ans Ziel. Das mindert das Erfolgserlebnis mitunter ;)
Danke für deine Hilfe!
Uwe
Hallo,
Allerdings habe ich auf Wunsch eines einzelnen Herrn (*g*) nochmal in meiner Firefox-Konfiguration gewühlt, und beim Überfliegen der Einstellungen in about:config habe ich mich erinnert, dass ich wegen genau demselben Problem (FF nimmt Ressourcen aus dem Cache, obwohl neuere auf dem Server verfügbar wären) vor langer Zeit mal browser.cache.check_doc_frequency auf 1 gesetzt habe. Mir hat das damals geholfen.
Bei about:config habe ich noch nie etwas getan weil ich schlicht keine Ahnung davon habe.
kann ich nachvollziehen, aber leider ist nur ein winziger Bruchteil der Firefox-Konfiguration über das GUI zugänglich. Ähnlich wie Windows selbst: Wenn man Hemmungen hat, Einstellungen direkt in der Registry vorzunehmen, kratzt man auch nur an der Oberfläche der Konfigurierbarkeit.
Und du hast immer noch nicht verglichen, worin sich die entsprechenden HTTP-Response-Header unterscheiden?
Ich dachte ich solle das mit netcat tun? ôO
Hmm, ja ... eher nein, meiner Ansicht nach.
Und was genau soll ich denn vergleichen? Sorry aber ich habe wohl ein ganzes Sägewerk vor dem Kopf. Den "ersten" Aufruf einer Seite (da ist ja logischerweise immer Status 200) oder nach einem refresh oder einfach URL neu eingeben? Und womit soll ich vergleichen? Mit den ganzen möglichen headern?
Nimm die LiveHTTP-Extension im Firefox, das ist das Anschaulichste, was mir dazu einfällt.
Schau dir einen der Response-Header an, wie sie bei einem "herkömmlichen" HTML-Dokument kommen - und dann einen, der mit deinem XHTML5-Dokument kommt. Und nicht nur den Status, sondern auch die restlichen Headerzeilen. Irgendwo muss ein wesentlicher Unterschied sein, der deinen FF im einen Fall veranlasst, das Dokument gutgelaunt zu cachen, und im anderen Fall eher nicht.
Teilweise lassen die Bezeichner der Headerzeilen schon ahnen, was sie bedeuten und bewirken, teilweise muss man nachforschen oder nachfragen, weil's sich einem nicht so einfach erschließt.
Reicht es nicht wenn ich sage ich bekomme Status 200 will aber 304?
Klar - wenn Browser und Server darauf hören. ;-)
Nein, nicht zwangsweise. Bisher hast du deine Dokumente nicht als application/xhtml+xml ausgeliefert, oder?
Mir war nicht klar, dass das einen Unterschied macht.
Mir auch nicht, aber das ist AFAIS der wesentliche Unterschied zu deinem bisherigen Vorgehen, also ist es naheliegend, das als "entscheidend" zu verdächtigen.
Es ist fast immer so, dass die Wege in der EDV steinig und mühsam sind. Aber wenn man dann schließlich am Ziel ist, war's doch irgendwie spannend und gibt einem ein Erfolgserlebnis.
Nach dem steinigen Weg kommt man aber oft mit gestauchten Gelenken ans Ziel. Das mindert das Erfolgserlebnis mitunter ;)
Stimmt. Aber die verstauchten und geprellten Gebeine heilen schnell wieder, und in drei Wochen erinnerst du dich nur noch an den Erfolg. Sportlern soll es angeblich ähnlich gehen.
Ciao,
Martin
Hallo Martin!
kann ich nachvollziehen, aber leider ist nur ein winziger Bruchteil der Firefox-Konfiguration über das GUI zugänglich. Ähnlich wie Windows selbst: Wenn man Hemmungen hat, Einstellungen direkt in der Registry vorzunehmen, kratzt man auch nur an der Oberfläche der Konfigurierbarkeit.
Ich habe heute ziemlich viel gelesen, auch über about:config, und auch eine Menge dabei gelernt. Mein Kopf glüht förmlich. Hier und hier hab ich mich auch erfolgreich durchgekämpft. Ich kann nun wohl die Geschichte mit den Headern und auch das ganze Caching-Gedöns zwischen Server, Proxy und Browser einigermaßen nachvollziehen.
Ich werfe hier aber mal ein, dass es mir ja eigentlich um die Grafiken ging die anscheinend immer mit Status 200 ausgegeben werden. Allerdings wird bei denen schon der Last-Modified-Header gesendet. Ich wundere mich aber ein bisschen über die Zeit: Sat, 05 Nov 2011 02:58:10 GMT
Das ist immerhin ~7h in der Zukunft.
Nimm die LiveHTTP-Extension im Firefox, das ist das Anschaulichste, was mir dazu einfällt.
Schau dir einen der Response-Header an, wie sie bei einem "herkömmlichen" HTML-Dokument kommen - und dann einen, der mit deinem XHTML5-Dokument kommt. Und nicht nur den Status, sondern auch die restlichen Headerzeilen. Irgendwo muss ein wesentlicher Unterschied sein, der deinen FF im einen Fall veranlasst, das Dokument gutgelaunt zu cachen, und im anderen Fall eher nicht.
Ich habe jetzt einfach mal 2 Beispiele online gestellt. Einmal als XHTML, einmal als XHTML5.
Vielleicht kannst du da ja mal schauen was falsch läuft.
Danke für deine Geduld!
Uwe
Hi,
Ich werfe hier aber mal ein, dass es mir ja eigentlich um die Grafiken ging die anscheinend immer mit Status 200 ausgegeben werden. Allerdings wird bei denen schon der Last-Modified-Header gesendet. Ich wundere mich aber ein bisschen über die Zeit: Sat, 05 Nov 2011 02:58:10 GMT
Das ist immerhin ~7h in der Zukunft.
Dann ist entweder die Serverzeit nicht korrekt eingestellt, oder der Änderungszeitpunkt der Grafiken wurde manuell (falsch) gesetzt.
Ich habe jetzt einfach mal 2 Beispiele online gestellt. Einmal als XHTML, einmal als XHTML5.
Da bekomme ich bei beiden beim Reload auch für die Hintergrundgrafik einen 304.
Aber so lange irgendwas mit der Serverzeit oder den Modified-Timestamps der Dateien nicht stimmt, ist es müßig, weiter das Cache-Verhalten zu betrachten – das muss erst mal korrigiert werden.
MfG ChrisB
Da bekomme ich bei beiden beim Reload auch für die Hintergrundgrafik einen 304.
Merkwürdig, ich bekomme durchgängig 200 egal ob Link, Adresse eingeben oder Refresh. So langsam habe ich auch das Gefühl, dass sich das Verhalten je nach Zeit ändert. Anfangs hatte ich wenigstens einen 304 wenn ich den Refresh-Button des Browser benutzt habe. Jetzt kommt nur noch 200. Als ob es von der Zeit abhängig ist wann man die Seite besucht. Es war ja auch gestern Abend um die Zeit als ich das Problem festgestellt habe. Vielleicht ist es aber nicht der Server sondern mein Provider (Kabel D-Land)? Wäre das auch möglich?
Aber so lange irgendwas mit der Serverzeit oder den Modified-Timestamps der Dateien nicht stimmt, ist es müßig, weiter das Cache-Verhalten zu betrachten – das muss erst mal korrigiert werden.
Oh man, mit dem Hoster wollte ich mich eigentlich nicht noch rumschlagen... :D
Aber du hast Recht, wenn die Zeit dermaßen daneben ist brauch ich den Fehler nicht weiter bei mir suchen. Das beruhigt mich extrem. Ich dachte langsam wirklich, dass XHTML5 dermaßen Aufwand nicht wert ist.
Merkwürdig ist auch, dass ich das Problem mit den nachgeladenen Grafiken, obwohl ich absolut nichts geändert habe, nicht mehr habe. Ich kann auch bei genauem Hinschauen kein kurzes Verschwinden und nachgeladen werden mehr erkennen.
Danke fürs Testen!
Uwe
... und jetzt ist auch der Last-Modified-Header glaubwürdiger ohne, dass ich die Daten neu hochgeladen hätte.
Ich versteh das Serververhalten nicht.
Wahrscheinlich kann also auch mein anderes Problem so erklärt werden.
Uwe
Ich habe jetzt einfach mal 2 Beispiele online gestellt. Einmal als XHTML, einmal als XHTML5.
Antwort-Header:
Date: Sat, 05 Nov 2011 02:27:09 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c
Last-Modified: Sat, 05 Nov 2011 02:27:09 GMT
Etag W/"4740dd-1c2-63b29780"
Accept-Ranges: bytes
Content-Length: 450
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Antwort-Header:
Date: Sat, 05 Nov 2011 02:30:07 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c
Last-Modified: Sat, 05 Nov 2011 02:30:07 GMT
Etag: W/"4740de-16e-63c1d9c0"
Accept-Ranges: bytes
Content-Length: 366
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/xhtml+xml
Date: Sat, 05 Nov 2011 02:30:07 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c
Last-Modified: Sat, 05 Nov 2011 02:30:07 GMT
Etag: W/"4740db-5746-fde49480"
Accept-Ranges: bytes
Content-Length: 22342
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: image/jpeg
In allen drei Fällen fehlen die Header für das Caching.
Stichworte:
Expires
Cache-Control
Beispiele:
Expires: Sat, 05 Nov 2011 05:30:07 GMT
Cache-Control: public, max-age=3600 (1 Stunde=60x60)
Hallo Otto!
In allen drei Fällen fehlen die Header für das Caching.
Stichworte:
Expires
Cache-Control
Beispiele:
Expires: Sat, 05 Nov 2011 05:30:07 GMT
Cache-Control: public, max-age=3600 (1 Stunde=60x60)
Ja das hab ich doch schon festgestellt^^
Wobei wir (ChrisB und ich) auch schon festgestellt haben, dass der Server auch noch ganz andere Sachen falsch macht. Da ich den Server aber wie gesagt nur angemietet habe, muss ich mich wohl mal mit dem Hoster auseinandersetzen.
Ich denke nicht, dass es mein Zuständigkeitsbereich ist mich um die korrekten Servereinstellungen zu kümmern. Davon abgesehen, dass ich, wie hier ja auch klar wurde, sehr wenig Ahnung davon habe. Als Mieter eines Webserver sollte ich Anspruch darauf haben, dass ich eine vernünftige Arbeitsumgebung bekomme und nicht etwas wo Serverzeiten nicht stimmen, Header fehlen und man das selbst mit ".htaccess-hacks" korrigieren muss.
Ich danke euch wirklich für eure geduldige Hilfe aber im Moment bin ich ein wenig genervt weil ich das Gefühl habe 2 Tage mehr oder weniger für etwas verschwendet zu haben von dem ich erwarte, dass es mein Hoster für mich erledigt.
Die schnelle Lösung wäre jetzt eine .htaccess die für die richtigen header sorgt (korrigier mich gern).
Uwe
Tagschön!
Die schnelle Lösung wäre jetzt eine .htaccess die für die richtigen header sorgt (korrigier mich gern).
Richtig. Denke an die Files oder FilesMatch-Direktive, damit dynamischer Content nicht beeinträchtigt wird. Letzteres kann auch der Grund sein, warum Dein Hoster diese Einstellungen nicht getroffen hat.
Grüße
Fred Furunkelstein
Tachschön!
Noch was:
Falls Du den Firebug benutzt, der kann verwirren:
Da steht bei einem Aufruf aus dem Chache auch immer der Status "200". Das die Daten aus dem Cache kommen erkennt man an der letzten Zeile: Wenn da was steht wie z.B. "118.8 KB (118.8 KB vom Cache)", dann stammen alle Daten aus dem Cache. Ob die einzelnen Ressourcen (HTML, CSS, JS-Files, Pics) aus dem Cache geladen wurden erkennst Du daran, dass in der Tabelle jeweils unter "RemoteIP" nichts steht. Kommen die Daten vom Server steht dort die IP.
Bei einem Refresh sollte bei den in die Webseite eingebundenen Ressourcen (CSS, JS, Pics) und einer der unten stehenden hinreichend ähnlichen Konfiguration der Status 304 stehen.
.htaccess (Beachte unten stehende Hinweise und Warnungen!):
<FilesMatch ".(png|jpg|jpeg|gif|bmp|ico|js|css|pdf)$">
<IfModule mod_headers.c>
Header set Cache-Control "max-age=604800,public,must-revalidate"
Header set Pragma "public" # für http-1.0 Proxy
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A604800
</IfModule>
</FilesMatch>
A)
Vorsicht, wenn Du einige der Ressourcen dynamisch erzeugst!
B)
Die Zahl 604800 repräsentiert eine Gültigkeit von einer Woche (7 Tage * 24 Stunden * 60 Minuten * 60 Sekunden), das "A" vor der Zahl bei ExpiresDefault repräsentiert die Anweisung, ab dem Zeitpunkt des Abrufes zu werten. "M" stände für Auswertung des Erstellungsdatums (Wird als header "LastModified" geliefert).
C)
Solltest Du mit Deiner .htaccess nicht umziehen, dann kannst Du ggf. auf <IfModule ...> </IfModule> verzichten. Ziehst Du jedoch mit dieser .htaccess auf einen Server um der Dir dies nicht bietet, dann bekommst einen 500er-Fehler und hast ggfs. heftig Probleme herauszufinden warum.
D) RTFM. Ich habe es nicht grundlos verlinkt.
Fred
Hallo,
Wie kann ich überprüfen ob die Dateien tatsächlich neu geladen werden
indem du den HTTP-Verkehr mitschneidest. LiveHTTP kennst du ja schon, vielleicht fehlt dir noch etwas Routine bei der Interpretation der Informationen.
Ich kenn mich nicht besonders mit den Angaben von Live HTTP Headers aus aber müsste ich nicht bei Dateien die im Cache liegen einen Status "not modified" bekommen?
Nur wenn der zugehörige Request eine solche Antwort sinnvoll erscheinen lässt. Dazu muss der Client den Header If-Modified-Since im Request mitliefern und ihn mit dem Timestamp ergänzen, der den im Cache verfügbaren Daten entspricht.
Im Klartext also: Falls sich die Ressource .... seit 03.11.2011 19:38 geändert hat, schick sie mir bitte nochmal aktuell. Und der Server antwortet darauf entweder mit Status 200 (Ok, da hast du), oder mit Status 304 (Ist unverändert, nimm deine Cache-Version).
Wenn die Ressource aber vom Server schon mit Headerzeilen ausgeliefert wird, die den Client bitten, die Daten nicht zu cachen, dann sieht der auch keine Veranlassung, ein If-Modified-Since zu senden.
So long,
Martin
