Permalinks, ModRewrite und der Firefox-Cache

Ich habe neben meiner WP-Installation im Wurzelverzeichnis auch noch ein kleines PHP-Skript zu liegen, welches mir die originalen Log-Dateien des Servers nach eingegangenen Suchmaschinenanfragen auswertet. Bei der Ausgabe der Ergebnisse verwende ich zur Formatierung eine CSS-Datei.
Nun hatte ich bei einer Umstellung zwar das PHP-Skript wieder aufgespielt, die CSS-Datei jedoch vergessen. Beim ersten Aufruf sahen die Ausgaben deswegen dann ein wenig komisch aus. Aber kein Problem dachte ich, CSS-Datei schnell nachgeschoben und das Skript neu gestartet. Nur änderte sich gar nichts, es sah so aus, als ob die CSS-Datei nicht existiert, obwohl sie definitiv da ist. Ein kurzer Gegencheck mit dem IE bestätigt dann auch, das eigentlich kein Problem vorliegt, hier wurde alles korrekt angezeigt.

Dann bin ich der Sache nachgegangen und habe den Ablauf rekonstruiert. Was passiert nun?

Die für die Permalinks eingestellten ModRewrite-Regeln prüfen zunächst, ob die angeforderte Ressource eine real existierende Datei oder ein Verzeichnis ist. In dem Fall liefert der Webserver die Daten selber aus, alles andere wird an die WP-eigene index.php weitergereicht.

Diese prüft, ob es sich um eine WP-Seite, also Artikel, Kommentar usw. handelt und gibt diese dann aus. Falls nicht, wir ein Fehler 404 erzeugt und die entsprechende Fehlerseite ausgegeben. Und genau hier liegt das Problem.

WP erzeugt im Fehlerfall mit der Funktion nocache_headers() einen entsprechenden HTTP-Response-Header, der zwar so Sachen wie:

Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache

enthält, aber auch ein Feld Last-Modified:,welchem die aktuelle Serverzeit zugewiesen wird.

Firefox scheint sich für die no-cache Sachen nicht so recht zu interessieren, sondern nimmt den Last-Modified-Eintrag als Anlaß, beim nächsten Aufruf im Request-Header mit If-Modified-Since dem Server die Möglichkeit zu geben, gegebenenfalls mit einem 304 Not Modified zu antworten.
Und genau das tut er dann korrekterweise auch, wenn die vorher vergessene Datei wieder da ist, aber ein Datum/Zeit-Wert von vor zwei Stunden, zwei Tagen oder zwei Jahren hat.

Worauf ich hinaus will, es ist aus meiner Sicht Unsinn, bei einem 404-Fehler einen Last-Modified-Eintrag mitzuschicken, denn was bitte soll diese Angabe darstellen. Von einer Ressource, die nicht da ist, kann ich schlecht sagen, wann sie das letzte mal geändert wurde. Der Apache selber schickt bei einem 404er übrigens keinen Datum/Zeitstempel mit.

Ich habe auch mal probeweise diese Last-Modified-Zeile in der WP-Funktion
nocache_headers() auskommentiert, und siehe da, die Welt ist wieder in Ordnung.

Gruß
Ingo

Zitat von mastermind

Zunächst mal ist festzustellen, dass der Apache bei 404 sehr wohl eine Datumsangabe mitschickt und dass es sehr wohl veränderliche 404-Seiten geben kann (z.B. Deine eigene wird ja auch dynamisch erzeugt). Meiner Ansicht nach ist es eher ein Bug im heiligen Firefox, dass er die HTTP-Header falsch interpretiert.

Naja, ich habe es testweise bei Apache selber probiert:
http://www.apache.org/bla
Das sieht bei mir der dann im Antwort-Header so aus:

HTTP/1.x 404 Not Found
Date: Wed, 10 Jan 2007 15:35:57 GMT
Server: Apache/2.3.0-dev (Unix)
Content-Length: 282
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Und wann die Fehlerseite erzeugt wurde, interessiert doch eigentlich nicht, die Antwort bezieht sich doch auf die angeforderte Datei, würde ich sagen.
Na zumindest führt es zu Problemen, die vermeidbar wären, wenn man keinen Last-Modified-Eintrag schicken würde.

Gruß
Ingo

Es gibt zumindest eine einfache Möglichkeit, den Last-Modified-Eintrag bei einem 404er zu unterdrücken, ohne die nocache_headers() - Funktion zu patchen.
Einfach am Anfang der header.php im Theme-Verzeichnis folgendes eintragen:

<?php
  if( is_404() ) {
    @header('Last-Modified:'); 
    @header('X-Pingback:'); 
  }    
?>

Aber wirklich ganz am Anfang, noch bevor DOCTYPE... kommt. Es darf halt noch keine andere Ausgabe erfolgt sein.
Was genau das X-Pingback macht, weiß ich jetzt nicht, aber mein Gefühl sagt mir, das es auch in einer Fehlerseite nicht unbedingt sinnvoll ist. :-)

Gruß
Ingo

Eben weil 404 ein sehr unspezifischer Fehler ist, und der Server nicht weiß, was nun genau die Ursache ist, sollte er keine Informationen senden, die er eigentlich nicht kennt. Wenn er die Ressource 'bla' nicht findet, kann er nicht wissen, wann diese zuletzt geändert wurde. Was passiert, wenn er es doch tut, habe ich ja oben beschrieben.
Die entsprechnenden Stellen in den RFcs habe ich gelesen und ich gebe zu, das mein Englisch nicht das beste ist. Vielleicht kann mir das hier ja mal jemand richtig übersetzten:

Zitat

[size=10]SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that
could result from using this date in an If-Modified-Since header
would lead to serious problems.[/SIZE]

So wie ich es verstehe, sollte ein Server, wenn machbar, einen [size=10]Last-Modified senden, außer es könnte in Folge dessen durch die Verwendung von [/SIZE][size=10]If-Modified-Since seitens des Clients zu Problemen kommen. Genau das tut es aber.

Wahrscheinlich ist aber alles, wie so oft, Auslegungssache.

Bei der Funktion header() wird standardmäßig ersetzt, nur wenn ich das nicht will, muß ich als zweiten Parameter false angeben. Aber es kann nicht schaden, explizit true zu verwenden. Vielleicht ändert sich ja mal die Spezifikation.;-)

Gruß
Ingo
[/SIZE]