Die Seiten sind alle da. Die Navigation funktioniert, die Adressen stimmen, im Quelltext steht jedes Stylesheet an seinem Platz. Nur sieht die Website aus wie 1996.
Das Symptom
Nach dem Umzug einer Website auf einen Plesk-Server war jede Seitenadresse erreichbar. Was fehlte, war alles mit einer Dateiendung: Stylesheets, Skripte, Bilder. Ausnahmslos 404.
Das ist ein ungewöhnliches Fehlerbild, weil es die naheliegenden Ursachen ausschließt. Wären die Pfade im HTML falsch, wären auch die Seitenadressen falsch. Wären es die Dateirechte, träfe es nicht ausgerechnet nur Dateien mit Endung.
Adressen ohne Endung funktionieren. Adressen mit Endung nicht. Wer dieses Muster sieht, muss nicht weiter in der Anwendung suchen – die Trennlinie verläuft im Webserver.
Die Ursache
Plesk betreibt in der Voreinstellung nginx als vorgelagerten Server vor Apache. Beide sind beteiligt, und wer welche Anfrage bekommt, entscheidet eine Einstellung je Domain: Intelligente Verarbeitung statischer Dateien.
Ist sie aktiv, beantwortet nginx alle Anfragen auf Dateien mit bekannter Endung selbst, direkt aus dem Dokumentenstamm. Das ist der Sinn der Sache – nginx ist darin schneller als Apache, und bei einer gewöhnlichen Website liegen diese Dateien genau dort, wo nginx sie sucht.
Die Folge für alles andere: Apache sieht diese Anfragen nie. Und damit auch keine .htaccess, denn die ist eine Apache-Angelegenheit. Jede Umschreibung, die Dateien aus einem anderen Verzeichnis erreichbar macht, läuft für diese Anfragen ins Leere.
Warum ausgerechnet hier
Websites mit mehreren Mandanten auf einem Dokumentenstamm legen ihre Dateien nicht dort ab, wo der Besucher sie anfragt. Angefragt wird /assets/stil.css, tatsächlich liegt die Datei unter shared/assets/stil.css. Die Brücke schlägt eine Regel in der .htaccess.
Auf einer klassischen Installation, bei der alles im Dokumentenstamm liegt, tritt der Fehler nie auf. Deshalb steht er in keiner Anleitung: Er braucht beides – nginx davor und eine Struktur, die umschreibt.
Zwei Behebungen
- In Plesk je Domain unter den Apache- und nginx-Einstellungen
- Danach reicht nginx alles an Apache durch, die .htaccess greift wieder
- Einfach, sofort wirksam, an einer Stelle nachvollziehbar
- Kostet den Geschwindigkeitsvorteil bei statischen Dateien
- Im Dokumentenstamm: ln -s shared/assets assets
- Ebenso für weitere betroffene Verzeichnisse
- nginx findet die Dateien jetzt dort, wo es sie sucht
- Geschwindigkeitsvorteil bleibt erhalten
- Muss bei jeder neuen Struktur mitgedacht werden
Bei geringem Aufkommen ist A die ehrlichere Wahl, weil die Regel dann an genau einer Stelle steht – in der .htaccess. B ist die richtige Wahl, sobald nennenswert Bilder ausgeliefert werden; dann sollte allerdings in der Aufbauanleitung stehen, dass die Verweise dazugehören, sonst fehlen sie beim nächsten Mal.
Was nicht hilft
- Zwischenspeicher leeren. Es wird nichts falsch ausgeliefert, es wird gar nichts ausgeliefert.
- Dateirechte prüfen. Die Dateien sind lesbar – nur nicht an der angefragten Stelle.
- Pfade im HTML korrigieren. Sie sind richtig. Falsch ist, wer sie beantwortet.
- Neu bauen. Die Dateien entstehen korrekt. Das Problem liegt hinter der Erzeugung.
Prüfung in einem Schritt
Zwei Aufrufe genügen, um die Weiche sichtbar zu machen: einmal auf eine Seitenadresse, einmal auf eine Datei mit Endung. Steht im Feld Server zweimal etwas Verschiedenes, ist die Ursache bestätigt, bevor man irgendetwas geändert hat.
Wo zwei Webserver hintereinander stehen, gilt eine Regel immer nur für den, der die Anfrage tatsächlich bekommt. Bevor man eine Regel debuggt, lohnt die Frage, ob sie überhaupt gelesen wird.