Neulich haben wir schon über den Unterschied zwischen 401 und 403 gesprochen. Jetzt wollen wir weiterschauen: der HTTP Code 500 ist ein weiterer häufiger Kandidat – und verhält sich „mysteriös“. Teilweise ist das aber auch gut so.

Frontend oder Backend?

Der HTTP‑Statuscode 500 bedeutet: Der Server ist intern auf einen Fehler gelaufen, den er nicht genauer spezifizieren kann oder will. Der 500er kommt also niemals aus dem Frontend. Das heißt wenn er auftaucht ist „irgendwas“ serverseitig falsch. Problem dabei: Er verrät nach außen hin nicht was bzw. wo. Manchmal wird er sogar richtig hart getarnt – z.B. in WordPress bei dem schlicht und ergreifend häufig nur „Deine Webseite hat einen kritischen Fehler“ oder etwas in der Art ausgegeben wird.

Das hilft natürlich als Entwickler nicht weiter.

Warum „nichts“ trotzdem gut ist.

Kann das trotzdem gut sein? Ja! Der 500er ist kein Feind – er ist ein Hinweis. Aber er gehört dorthin, wo er hingehört: ins Log, nicht ins Live‑System. Denn das verhindert, dass wichtige oder kritische Infos direkt nach draußen gespielt werden. Man stelle sich vor: Ein solcher Fehler trifft auf Google – und Google indiziert es weil es das für regulären Inhalt hält (gut würde es nicht, weil der Statuscode 500 immer noch sagt „das ist ein harter Fehler“ – und Google das weiß).

Aber es gibt ja auch noch die bösen Jungs (und auch Mädels 😉 ) da draußen und für die wäre es Gold wert. Und für den Standardbenutzer? Der würde sowieso drauf schauen und sagen: Ich versteh nur Bahnhof.

Wichtig dabei auch zu verstehen: Der 500 ist kein 503. Ein 500 bedeutet es gab einen kritischen Fehler. Ein 503 hingegen bedeutet, der Server (ohne ein wichtiger Teil davon) ist gerade nicht verfügbar. Ein 503 kann je nach Konfiguration bedeuten, der Apache, Nginx oder ein entsprechender anderer Webserver ist gerad nicht verfügbar (z.B. wegen fehlerhafter Konfiguration nicht gestartet). Es kann aber auch heißen – je nach dem wie z.B. PHP eingebunden ist, dass der Apache/Nginx/Webserver zwar läuft aber der dahinterliegende PHP-Teil nicht erreichbar ist. Denn technisch reicht der Webserver die Anfrage ja nur durch und nimmt die Antwort zum zurückreichen an den Browser wieder entgegen.

Kann man das auch gezielt nutzen?

Theoretisch ja. Praktisch tut es fast niemand weil viele (leider) Status und Inhalt verwechseln oder besser gesagt beides in einen Topf werfen. Aber ja, man könnte einen 500er zurückgeben auch wenn es eben kein „Systemabsturz“ ist sondern man nur gezielt drauf hinweisen will „irgendwas passt hier ganz gewaltig nicht“. Natürlich sollte man das sehr sparsam tun – auch wegen Google: Wirft eine Seite dauerhaft „harte Fehler“ gilt sie als technisch nicht ausgereift und das ist eher zum Nachteil für eine Topplatzierung.

Und wie verhindere ich das?

Naja für alles was mit PHP zu tun hat: PHPUnit-Tests sind ein großartiger Baustein. Und natürlich auch gern Tests auf einem Testserver bevor man „Live“ geht. Das machen wir bei eproi sowieso. Bevor wir etwas auf ein Livesystem geben, wird immer lokal oder auf einem Testserver – ggf. gern auch in beiden Schritten – gegengetestet. Denn da kann man dann auch Logging und Fehlerausgabe nutzen. Das behebt zwar nicht den Fehler aber dann sagt PHP zumindest, wo es klemmt. Übrigens: Bei anderen Sprachen gibt es auch Testframeworks und zumindest mal auf einem Testsystem ausprobieren kann man auch ganz ohne Testsystem – das übrigens schon immer… 😉