nicht angemeldet
Hallo Michael!
wenn Du HTTP/1.0 unterstützen willst (und statische Seiten auslieferst, also keine Skripte hast, die ihre Header selbst erzeugen), dann ja. Für HTTP/1.1 mit "Cache-Control" mußt Du nicht mit dem Datum herum rechnen - da würde schon mod_headers reichen.
Hm. HTTP/1.1, welche Clients können das nicht? Die 4er? Aber mit <meta> Tags im Dokument hjat das doch nicht viel Sinn, oder würdest Du denen bzw. den Browsern bzgl. dessen Befolgung genauso vertrauen wie HTTP-Headern?
Außerdem - was wenn Du eine Datei dann dochmal geändert hast?
Den Charakter seiner Seiten muß man natürlich schon verstehen.
Ich habe für Bilder sehr viel höhere Caching-Perioden eingestellt als für HTML-Seiten; und vor einem Releasewechsel unserer Serverfarm schalte ich diese Caching-Unterstützung in der Tat ein paar Tage lang ab, um die Caches unterer Kunden zu "säubern".
Mein "Problem", ich habe keine festen HTML-Seiten, sondern das ganze ist _sehr_ dymanisch. Auf manchen Seite ändert sich die Ausgabe bei jedem Reload, und bei anderen kann sie sich zumindest jederzeit ändern. Das ist mir zu riskant, das werde ich wohl lieber nicht cachen. Anders ist es wie gesagt bei Grafiken, Javascripten und CSS.
Und da lässt sich bestimmte ne ganze Menge machen, teilweise habe ich 4 Javascript-Links, 2 CSS-Links und unzählige kleine Grafiken auf der Seite(btw. - wenn ein Recourcenname in einer HTML-Datei mehrmals vorkommt wird doch nur _ein_ Request gestartet, oder?), jedemnfalls ist hier sicher viel Potential!
Kann ich eigentlich auch bestimmte Javascript-Dateien vom Caching ausnehmen, wenn ich das serverseitig konfiguriere?
Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wichtiges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen.
Das Forum hier läßt sogar seine Hauptdatei 60 Sekunden lang cachen - man muß halt wissen, was man tun will.
Ist das immer noch so? Ne Zeit lang hatte man das gemerkt, im MOment merke ich davon nichts! Wenn ich einen Beitrag poste uidn sofort danach die Hauptseite aufrufe gibt es da nie eien Verzögerung, also sind entweder meien Caching-Einstellungen nicht korrekt, oder es gibt keine Header, aber das lässt sich ja kontrollieren... Aha, zumindest im /-Bereich gibt es die Header noch. Komisch...
Ich meinte damit eigentlich das "chunking" was - wenn ich das richtig verstanden habe - bedeitet, dass der Browser die Pakete nicht nacheinander abfragt und in der Richtigen Reihenfolge empfängt, sondern dass die Daten parallel ggfs. auch in falscher Reihenfolge gesendet werden
Hm - da kenne ich mich auch nicht wirklich aus. Mein Wissensstand ist, daß man Chunking wohl vor allem dann braucht, wenn man die Ausgabe derartig inkrementell erzeugt, daß man zu Beginn der Ausgabe eben noch nicht weiß, welche "Content-Length" man in den HTTP-Header hätte schreiben müssen. HTTP enthält halt keine Klammerstruktur, mit welcher der Sender dem Empfänger mitteilen kann, daß das Paket fertig ist; entweder macht man so etwas über die Content-Length, oder eben darüber, daß der Client mit chunks fertig werden können muß.
Ich muss gestehen ich habe es vergessen wie das genau funktioniert hatte, und leider kann ich das mit meinem Mozilla Firebird auch nicht mehr einstellen. Es gab da aber definitiv 2 Einstellmöglichkeiten, einmal keep-alive, und einmal "chunked Irgendwas". Ich bin anscheinend auch etwas zu blöd mal ne anständige Dokumentation zu Mozilla online zu finden.
nur kann das nicht jeder Server, wenn ich das z.B. mit Mozilla bei google anstelle, bekomme ich da immer einen ziemlich bunten Seitensalat zurück ;-)
Ups - jetzt weiß ich gar nicht, was Du meinst. Vielleicht bist Du gerade beim Thema "persistente Übertragung" (keep-alive)? Das ist wieder ganz was anderes (mehrere HTTP-Requests innerhalb einer TCP/IP-Verbindung) und würde zu Deiner Thematik viel besser passen ...
Das kenne ich und das meine ich sicher nicht. Es ging glaueb ich grob darum, dass ohne chunked encoding nach einem Request imme rgewartet wird, bis die Anwort vollständig da ist, bei chunked encoding ist das egal, da kann nach dem ersten Request sofort der nächste gestartet werden, ohne warten zu müssen dass eine Antwort auf den ersten eingegangen ist. Dafür wird es jetzt schwieriger die Antworten des Servers zuzuprdnen, dass müssen Server und Client unterstützen. Zumindest so in die Richtung ging das, ich habe es mal eingeschaltet weil ich es eigentlich effektiv fand, aber leider haben dann einige Seiten wie Google eben verrückt gespielt, die Bilder waren z.B. total verzerrt oder ganz komisch.... da hat dann irgendwas nicht so gfeklappt wie es sollte. Vielleicht ist es auch ein Mozilla-Problem gewesen.
Aber zu einem anderen Thema, was hier vielleicht auch ganz gut hinpasst. Wie oben beschrieben sind alle HTML-Seite dymanisch, also die Ausgabe von PHP-Scripten. Hier verwende ich eien globale Einstellung das jede Ausgabe von PHP gzip-komprimiert ausgegeben wird. Was jetzt aber nicht komprimiert wird, sind die Javascripte(die teilweise auch etwas größer sind), und die CSS-Dateien. Wie komprimiere ich diese jetzt am besten? Oft werden die eh nicht verändert, die Frage ist, ob es Sinn macht mod_gzip zu installieren, obwohl ich es nur für die Verhältnismäßig wenigen Dateien brauche. 2 Variante wäre mit Content-Negotiation zu arbeiten, d.h. ich erstelle manuell auch ...js.gz und ...css.gz Dateien, die ich dann mit "options multiview" in der httpd.conf des Apachen entsprechend ausgeben lasse. Noch eine Variante wäre es, die Komprimierung der HTML-Ausgabe der PHP-Scripte nicht PHP, sondern mod_gzip zu überlassen, was haltet Ihr davon? Eigentlich wäre das ja nicht nötig, also müsste der Weg mit PHP und kpl. ohne mod_gzip der effektivere sein, oder?
Viele Grüße
Andreas