Chaching im Chrome/Apache/PHP

[M.]

Mahlzeit,

ich bin jetzt auf Mint/MATE (aktuell) umgestiegen. Vorher hatte ich Squeeze drauf, was halt schon älter war.

Jetzt muss ich den Chrome 2-4mal neu laden, damit ne neue Seite vom Server geholt wird.

Folgende Konstellation:

PHP5.5.6
Smarty3
Apache2.4.6
Chrome34

Geändert zu vorher hat sich PHP, Apache und Chrome.
Chrome fragt auf jeden Fall beim Apache an und bekommt Daten geliefert, also vermute ich das Chaching beim Apache. Da sich an der Smarty-Config nix geändert hat (und das Verhalten bei gelöschten template_c gleich ist), schliesse ich diese Komponente mal aus.
Da es mein erster Kontakt mit Apache2.4 ist, wäre es nett, wenn mir jemand meinen Verdacht bestätigen oder dementieren kann.

Es ist halt nervig, immer mehrmals neu laden zu müssen.

[M.]

Mahlzeit,

kleiner Nachtrag: Server läuft mit FastCGI

[hotti]

Da es mein erster Kontakt mit Apache2.4 ist, wäre es nett, wenn mir jemand meinen Verdacht bestätigen oder dementieren kann.

Welche Cache-relevanten Header werden nun gesendet?

[M.]

Mahlzeit,

Welche Cache-relevanten Header werden nun gesendet?

Ich hab diesen PHP-Code hier:

  
		header("Content-Type: text/html; charset=$a_charset");  
		header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");  
		header("Cache-Control: no-store, no-cache, must-revalidate");  
		header("Cache-Control: post-check=0, pre-check=0", FALSE);  
		header("Pragma: no-cache");  

Diese Code hat sich nicht geändert. Hat sich da was bei Chrome geändert?
Ich muss zugeben, ich lese nicht immer die neuen Features durch, wenn ich ein Update installiere ;)

Hier mal das, was im Chrome ankommt:

Source:

  
HTTP/1.1 200 OK  
Date: Fri, 02 May 2014 08:48:16 GMT  
Server: Apache/2.4.6 (Debian)  
X-Powered-By: PHP/5.5.6-1  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0  
Pragma: no-cache  
Vary: Accept-Encoding  
Content-Encoding: gzip  
Content-Length: 1278  
Keep-Alive: timeout=5, max=91  
Connection: Keep-Alive  
Content-Type: text/html  

Parsed:

  
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0  
Connection:Keep-Alive  
Content-Encoding:gzip  
Content-Length:1258  
Content-Type:text/html  
Date:Fri, 02 May 2014 09:31:01 GMT  
Expires:Thu, 19 Nov 1981 08:52:00 GMT  
Keep-Alive:timeout=5, max=94  
Pragma:no-cache  
Server:Apache/2.4.6 (Debian)  
Vary:Accept-Encoding  
X-Powered-By:PHP/5.5.6-1  

Also ich seh da kein Problem. Da ich das Problem bisher nicht hatte, hab ich mich damit auch nicht näher befasst.

[hotti]

hi,

Also ich seh da kein Problem. Da ich das Problem bisher nicht hatte, hab ich mich damit auch nicht näher befasst.

OK, dann machen wir das jetzt ;)

Es ist möglich, dass der Webserver aufgrund seiner Konfiguration die Header, die von PHP her kommen, nicht durchreicht, sondern was Anderes macht.

Ich würde so vorgehen:
header('Last-Modified'); # nicht setzen
Obwohl er offensichtlich nicht durchgereicht wird.

Dann sollte eigentlich auch kein Expires-Header ankommen, es sei denn der Webserver setzt irgendeinen von selbst, gehe in die .htaccess:

  
# alle  
ExpiresActive off  
  
# oder gezielt  
<Files "*.appcache">  
    ExpiresActive off  
</Files>  

Und dann schauen wir mal, ob der Expires-Header noch am Browser ankommt.

[Der Martin]

Hallo,

Es ist möglich, dass der Webserver aufgrund seiner Konfiguration die Header, die von PHP her kommen, nicht durchreicht, sondern was Anderes macht.

du hast aber schon gesehen, dass M. die Header gezeigt hat, wie sie beim CLient (Chrome in seinem Fall) ankommen, und dass die mit den von PHP "bestellten" Headern übereinstimmen? - Nun, mit einer Ausnahme: M. gibt mit PHP den Content-Type-Header mit einer Angabe zur Zeichencodierung aus, Chrome gibt diese Angabe aber nicht wieder. Wo die verlorengeht, wissen wir nicht. Aber zumindest hat das nichts mit Caching zu tun.

Vielleicht aber die Last-Modified-Angabe, die der Server in einen Expires-Header ummünzt? Wir sehen an M.s Code nicht, welches Datum er wirklich setzt und warum im Expires-Header ein derart krummes Datum rauskommt. Alles andere passt ja zusammen ...

Ciao,
 Martin

[hotti]

Vielleicht aber die Last-Modified-Angabe, die der Server in einen Expires-Header ummünzt? Wir sehen an M.s Code nicht, welches Datum er wirklich setzt und warum im Expires-Header ein derart krummes Datum rauskommt. Alles andere passt ja zusammen ...

In PHP wird Expires nicht gesetzt, habe ich gesehen. Ergo setzt der Webserver spontan diesen Header mit einem Datum was in der Vergangenheit liegt: Jawohl das ist schon etwas krumm und nicht empfehlenswert.

Was machen wir also? Wir konfigurieren den Webserver so, dass er Expires gar nicht mehr sendet.

Nicht meckern sondern machen. Und dann schauen wir mal weiter ;)

[M.]

Mahlzeit,

Und dann schauen wir mal, ob der Expires-Header noch am Browser ankommt.

Musste erstmal das passende Apache-Modul aktivieren ;)
Dummerweise kommt der Header immer noch im Chrome an.

  
Date:Fri, 02 May 2014 10:55:29 GMT  
Expires:Thu, 19 Nov 1981 08:52:00 GMT  
Keep-Alive:timeout=5, max=100  
Last-Modified:Fri, 02 May 2014 10:55:30 GMT  

Was aber komisch, die Uhrzeit stimmt nicht überein. Aktuell die Seite aufgerufen, trotzdem Date und Last-Modified genau 2 Stunden hinterher.

Kann es sein, dass das Time-Offset in PHP falsch ist und es sich auf den Cache auswirkt?
Das Offset arbeitet noch nicht ganz richtig, das weiss ich, aber bisher hatte sich das zumindest nicht auf den Cache ausgewirkt.

Ich muss jetzt weg, werd mich also erst heute Abend weiter mit dem Thema befassen können. Danke schonmal für die Tipps :)

[Der Martin]

Hallo,

Date:Fri, 02 May 2014 10:55:29 GMT
Last-Modified:Fri, 02 May 2014 10:55:30 GMT

Was aber komisch, die Uhrzeit stimmt nicht überein. Aktuell die Seite aufgerufen, trotzdem Date und Last-Modified genau 2 Stunden hinterher.

eigentlich nicht: 10:55 GMT ist 12:55 MESZ. Passt doch! :-)
Nur der Expires-Header mit dem Phantasiedatum passt so gar nicht ins Schema.

Ciao,
 Martin

[M.]

Mahlzeit,

eigentlich nicht: 10:55 GMT ist 12:55 MESZ. Passt doch! :-)

Stimmt, das kommt davon wenn ich nicht genau lese ;)

Nur der Expires-Header mit dem Phantasiedatum passt so gar nicht ins Schema.

Der kommt aber definitiv vom Apachen, denn im FF hab ich den auch drin.
Allerdings nur bei meinem PHP, nicht wenn ich eine HTML-Seite aufrufe.
Ich muss jetzt mal suchen, ob der doch irgendwo gesetzt wird, ohne dass ich es weiss. Das Projekt hab ich ja schon seit 7 Jahren in Arbeit ;) Da schleichen sich beim erweitern immer wieder Bugs ein.

[Jörg Reinholz]

Nur der Expires-Header mit dem Phantasiedatum passt so gar nicht ins Schema.

Der kommt aber definitiv vom Apachen, denn im FF hab ich den auch drin.

Vielleicht ja von Smarty?

Smarty kann auch selbst cachen und ich stelle mal in den Raum, dass es die Header teilweise auch selbst anpasst. Die ob_* Funktionen sollten auch das Überladen vorheriger, mit header() gesetzter Einträge erlauben.

Prüfe also mal Deine Smarty-Konfiguration.

Jörg Reinholz

[M.]

Mahlzeit,

Prüfe also mal Deine Smarty-Konfiguration.

Hab ich, die hat sich aber nicht geändert. In meiner dev-Version erzeugt Smarty (nutze Version 3) jedesmal das Template neu.

Ich werd mir das aber trotzdem mal ansehen, kann ja ne Wechselwirkung mit dem neuen Apachen sein.
Ich teste morgen mal, wie es in anderen Browsern aussieht, heute muss ich noch einiges andere machen ;)

Danke für deine Mühe :)

[M.]

Mahlzeit,

An Smarty liegts nicht, die CSS-Dateien werden auch gecached. Aber ich komm noch dahinter ;)

[M.]

Mahlzeit,

nur als Abschlussinfo, da ich das Problem gefunden habe.
Es lag tatsächlich an Smarty3. Wieso sich das Caching in Smarty auf einem Apache 2.2 anders auswirkt als auf Apache 2.4 kann ich nicht sagen, aber es ist so.