Symfony Internal Server Error 500 Titelbild

Man freut sich vielleicht gerade eine Anwendung fertig gestellt zu haben, will diese nun Online bringen und plötzlich meldet sich ein 500 Internal Server Error.
Häufig kommt es vor, das sich die Bildschirmausgabe des Webprojektes in der Entwicklungsumgebung ( Dev Environment ) von der Produktiv-Umgebung (Prod Environment) unterscheidet.

Beim Entwickeln überprüft man die Anwendung z.B. via Webbrowser
http://localhost:8000/unterseite/artikel

wenn o.g. URL nun wie folgt erweitert wird:

http://localhost:8000/app.php/unterseite/artikel (entscheidend ist hierbei app.php)
kann getestet werden, wie sich die Anwendung mit Prod-Environment (Produktiveinsatz) verhalten würde. Ist optisch und funktional alles wie beim 1. Link, so ist dies ein gutes Zeichen und die Anwendung ist bereit Online zu gehen.

Warum verhalten sich beide Aufrufe unterschiedlich?

Dies kann zum einen auf die Anwendungskonfoguration zurückzuführen sein, welche ggf. für das Dev-Environment ausgelegt ist oder man nutzt innerhalb der Entwicklung Module von Symfony, die lediglich für den Entwicklungsprozess gedacht sind und live bzw. im Prod-Environment nicht zur Verfügung stehen.

Triviales Beispiel für die Erzeugung eines 500 Internal Server Error – kein dump im Prod

Beim Entwicklungsprozess wird ggf. des Öfteren auf die dump-Funktion von Symfony zurückgegriffen um sich Inhalte während der Datenverarbeitung anzeigen zu lassen.
Der Dump von Inhalten funktioniert hierbei sowohl aus einem Twig-Template oder auch über einen der Controller.
Dies ist für die Entwicklung sehr nützlich, jedoch für die online geschaltete Webanwendung sehr gefährlich. Angenommen die Dumps werden nicht entfernt (Vergesslichkeit), dann würden die Ausgaben einem zukünftigen Betrachter der Webanwendung interne Strukturen offen legen, also ein gefundenes Fressen für potentielle Angreifer. Daher steht die dump-Funktion nur im dev-Environment und nicht im prod-Environment zur Verfügung.

Symfony Prod Error Log – Informationen zum Fehlverhalten der Website auslesen

Angenommen die Live geschaltete Anwendung wirft nun ein 500 Internal Server Error oder andere Fehlermeldungen, so quittiert Symfony diese innerhalb eines Logfiles ( dieses findet man unter app/logs/ ).

Eine Eintrag aus dem Logfile könnte wiefolgt aussehen:
[2016-07-20 14:28:16] request.CRITICAL: Uncaught PHP Exception Symfony\Component\Debug\Exception\UndefinedFunctionException: „Attempted to call function „dump“ from namespace „AppBundle\EventListener“.“ at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php line 27 {„exception“:“[object] (Symfony\\Component\\Debug\\Exception\\UndefinedFunctionException(code: 0): Attempted to call function \“dump\“ from namespace \“AppBundle\\EventListener\“. at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php:27)“} []

Beim betrachten der Log-Line stößt man nun auf UndefinedFunctionException(code: 0): Attempted to call function \“dump\“. Dies bedeutet das ein Ausnahmefehler (Exception) geworfen wird weil die dump-Funktion nicht exisitert.

Was kann man gegen den Error machen?

Das zuvor gennante Beispiel zeigt, das Dumps in im Prod-Environment nicht funktionieren. Die Anwendung muss daher auf den Einsatz dieser Ausgaben geprüft werden. Entfernen / auskommentieren und erneut testen, ob der Internal Server Error bestehen bleibt.

Handelt es sich nicht um o.g. Szenario, so ist die Ursache so pauschal nicht zu ermitteln und benötigt ggf. Untersuchungen des Quellcodes oder der Konfiguration.
Zunächst ist es jedoch Sinnvoll sich einen Überblick über die Fehlermeldungen (HTTP-Status Codes) zu verschaffen. Eine Liste mit allen Status-Codes ist hier zu finden.

So kann das Problem zumindest schon mal grob eingegrenzt werden (z.B. Inhalt nicht gefunden Error 404 oder einer 500er Meldung). Weiterhin sollten die Error-Logs unter /app/logs (Symfony Nutzer) oder Log-Files Ihres Webservers betrachtet werden. Es ist erstaunlich, wie schnell man dem Fehler durch die Log-Files auf die Schliche kommt.

Literaturempfehlung für den Umgang und Erweiterung von Symfony

Werbeanzeige:
extending_symfony2
Extending Symfony 2 Web Application Framework
[Author: Sebastien Armand]