Es gibt Fehler, die sich sofort zeigen, und es gibt Fehler, die auf ihren Anlass warten. Dieser hier wartete auf den Umzug.

Der Aufbau

Eine Weiterleitungsverwaltung kann auf zwei Wegen wirken. Der eine schreibt einen fertigen Regelblock, den man in die .htaccess übernimmt – ohne PHP, dafür bei jeder Anfrage mitgelesen. Der andere hängt sich in die Fehlerbehandlung: Findet der Server nichts, ruft er ein Skript auf, das nachsieht, ob für diese Adresse eine Regel hinterlegt ist.

Der zweite Weg ist der bessere, sobald es um mehr als eine Handvoll Regeln geht. Er kostet einen Aufruf – aber nur bei Adressen, die es ohnehin nicht gibt.

Woran er hängt

An zwei Zeilen in der .htaccess, und beide sind leicht zu übersehen:

1️⃣Die Fehleranweisung muss auf das Skript zeigen

Steht dort die gewöhnliche Fehlerseite, wird sie ausgeliefert und das Skript nie aufgerufen. Der Server verhält sich vollkommen korrekt – nur eben ohne die Weiterleitungen.

2️⃣Das Skript muss von der Umschreibung ausgenommen sein

Sonst greift die interne Weiche zuerst und leitet den Aufruf auf eine erzeugte Seite um, die es nicht gibt. Das Skript ruft sich dann faktisch selbst nicht auf.

Das täuschende Fehlerbild

Die Verwaltungsoberfläche zeigt die importierten Regeln. Die Datenbank enthält sie. Die erzeugte Zuordnungsdatei enthält sie ebenfalls. Jede Kontrolle, die man üblicherweise anstellt, ist grün.

Warum das erst spät auffällt

Die einzige Prüfung, die den Fehler zeigt, ist der Aufruf einer alten Adresse. Genau die ruft vor dem Umzug niemand auf – auf dem alten System funktioniert sie ja noch. Und nach dem Umzug ruft sie zuerst eine Suchmaschine auf, nicht der Betreiber.

Die Prüfung, die dazugehört

  1. Eine Adresse mit hinterlegter Weiterleitung

    Erwartet wird der Status 301 und das richtige Ziel im Antwortkopf. Kommt 404, greift der Rückfall nicht.

  2. Eine Adresse, die entfallen soll

    Erwartet wird 410. Kommt 404, ist die Regel zwar da, wird aber nicht gelesen – dasselbe Bild wie oben.

  3. Eine Adresse ohne Regel

    Erwartet wird 404 mit der eigenen Fehlerseite. Kommt hier 200, ist die Fehlerbehandlung insgesamt falsch verdrahtet und meldet Erfolg, wo nichts gefunden wurde.

Der eigentliche Punkt

Eine Regel, die in der Datenbank steht, ist keine Regel, die wirkt. Zwischen beidem liegt der Aufrufweg – und der ist der Teil, den niemand prüft, weil er nicht wie ein Teil der Funktion aussieht.

Das gilt über diesen Fall hinaus für alles, was über eine Fehlerbehandlung, einen Zeitplaner oder einen Auslöser angestoßen wird: Die Sichtprüfung der Daten sagt nichts darüber aus, ob der Weg dorthin überhaupt beschritten wird.

Weiterlesen Wo die HTTPS-Regel steht Wenn nginx die .htaccess überholt