HTTP ERROR 500 statt PHP Fehlermeldungen?

[Brombeermilchtrinker]

Hallo Domainfactory Team,

ich habe schon sehr lange kein Debugging mehr mit Seiten auf dem Server gemacht, darum weiß ich nicht, wie lange die Situation, die ich gerade bemerkt habe, schon existiert.

Ich stelle fest, dass eine PHP Ressource mit einem Syntaxfehler auf dem Domainfactory Server plötzlich keine Fehlermeldung mehr ausgibt, sondern einen kommentarlosen HTTP ERROR 500, wo man außer "Diese Seite funktioniert nicht" nichts zu sehen bekommt.

BITTE sagt mir, dass die Nichtausgabe von PHP Fehlermeldungen nicht Euer Ernst und Eure Absicht ist sondern der Fehler/Grund bei mir liegt!?!?

Wenn ich lokal mit XAMPP absichtlich folgendes Skript schreibe ...

<?php
$haus = "hoch;
echo $haus;
?>

... dann bekomme ich (wie erwartet und wie gewünscht!) "Parse error: syntax error, unexpected end of file in G:\XAMPP\htdocs\MICHAEL\2022_MPL_XXII\CODE_Version \ROOT\sites\fehlertest.php on line 4" ausgegeben.

Die selbe Seite am Domainfactory Server bringt mir beim Aufruf wie beschrieben nur "Diese Seite funktioniert nicht ... HTTP ERROR 500".

Das kann und darf doch nicht sein?! Wie bitte soll man bei langen und komplexen PHP Skripten, die Fehler enthalten, je ein Debugging machen ohne einen Hinweis durch die PHP Fehlermeldung???

Was bitte ist da los? Wie gesagt, ich hoffe, der Fehler liegt bei mir. Wenn das beabsichtigt ist, dann war's das für mich hier.

Liebe Grüße & Bitte um Aufklärung/Hilfe!

Der Brombeermilchtrinker

[Gast]

Das kann und darf doch nicht sein?! Wie bitte soll man bei langen und komplexen PHP Skripten, die Fehler enthalten, je ein Debugging machen ohne einen Hinweis durch die PHP Fehlermeldung???

Indem Du Dich mit Error reporting und den Einstellungen (https://www.php.net/manual/de/functi...-reporting.php) beschäftigst. Auf einem produktivsystem (=öffentlich erreichbar) sollte niemals eine PHP Fehlerausgabe stattfinden, da dort dann Fehler auch Hinweise für mögliche Angreifer darstellen können.
Lange Scripte sind zu vermeiden, mittels Exceptions sind Fehler abzufangen und einfache Syntaxfehler wie der von Dir hier zitierte sollte Dein Editor direkt anmeckern beim Schreiben des Codes.

[Brombeermilchtrinker]

Indem Du Dich mit Error reporting und den Einstellungen (https://www.php.net/manual/de/functi...-reporting.php) beschäftigst.

Ich brauche mich mit Errorreporting nicht beschäftigen, ich weiß, was das ist und was die Einstellungen bewirken. Abgesehen davon ändert selbst ein error_reporting(E_ALL|E_STRICT); nichts am Geschehen.

Auf einem produktivsystem (=öffentlich erreichbar) sollte niemals eine PHP Fehlerausgabe stattfinden, da dort dann Fehler auch Hinweise für mögliche Angreifer darstellen können.
Lange Scripte sind zu vermeiden, mittels Exceptions sind Fehler abzufangen und einfache Syntaxfehler wie der von Dir hier zitierte sollte Dein Editor direkt anmeckern beim Schreiben des Codes.

Dieser Syntaxfehler war nur ein Beispiel und ja, selbstverständlich sieht man so eine offensichtliche Kleinigkeit schon im Editor. Aber es geht ja nicht nur um sowas, sondern auch um Tippfehler bei Variablen, fehlenden Ressourcen bei includes ... oder was auch immer. Und auch der Rest der Antwort hat mir keine neuen Erkenntnisse gebracht. Mir ist schon klar, dass man bei Projekten, die on air sind, keine Fehlerausgaben liefert und auch mit Exceptions weiß ich umzugehen.

Das beantwortet mir trotzdem nicht, wieso hier jahrelang, wenn von mir gewünscht, ein PHP Skript mit Fehlern zu entsprechenden Fehlermeldungen geführt hat und das nun nicht mehr so ist. DAS will ich gerne wissen, am besten, ohne mich belehren lassen zu müssen über Dinge, die ich erstens weiß und die zweitens für die Beantwortung meiner Frage völlig irrelevant sind!!

[Gast]

Allles klar, ich konnte ja nicht wissen, dass Du alles weißt! Ich ziehe meine Antwort hiermit zurück.

[masterframe]

display_errors muss auch aktiviert sein.

https://www.php.net/manual/de/errorfunc.configuration.php

Was sagt den eine phpinfo() zu den Punkten?

[Brombeermilchtrinker]

display_errors muss auch aktiviert sein.

https://www.php.net/manual/de/errorfunc.configuration.php

Was sagt den eine phpinfo() zu den Punkten?

Das war tatsächlich nicht aktiviert, ändert aber nichts an der Entstehung eines 500er Status. (Zu dem es auch nicht kommen dürfte, selbst wenn display_errors OFF ist!)

Übrigens: Nach der Aktivierung von display_errors über den Punkt ".user.ini editieren" im Kundenmenü steht dort zwar "Neue .user.ini wurde installiert und ist sofort aktiv" ... wenn ich dann aber mit Filezilla meinen Webspace durchsuche, finde ich weder eine .user.ini, die laut den FAQ angeblich im Hauptverzeichnis einer Domain sein soll, und schon gar keine reguläre php.ini. (Letzteres ist wohl gewollt)

Also seit ich mich überreden habe lassen, auf das neue Serversystem umzusteigen, sehe ich nur noch Nachteile und Probleme, die ich davor jahrelang nicht hatte.

[masterframe]

Ein 500er wird meistens durch eine fehlerhafte .htaccess verursacht.
Kannst du ausschließen, dass bei dF eine .htaccess in dem Ordner oder einem übergeordneten liegt?

[Lukas M.]

Bei allem verständlichen Unmut gegenüber dF:

Ein Syntax-Fehler z.B. oder ein Abbruch aufgrund zu viel Resourcennutzung liefert ohne entsprechende Konfiguration (wie u.A. display_errors=on - was übrigens bei XAMPP per Default an ist weil XAMPP nicht für Produktivsysteme gedacht ist) natürlich auch einen generischen 500er-Fehler. Das ist absolut korrekt so und auch Standard.
Auch dass du auf die normale php.ini keinen Zugriff hast ist Standard. Genau dafür gibt es seit Jahren bei mod_php die htaccess und bei PHP-FPM und Co die .user.ini: https://www.php.net/manual/de/config...e.per-user.php

Wo die bei dF genau liegt kann ich dir tatsächlich aber auch nicht aus dem Stegreif sagen. Evtl. versteckte Dateien in deinem Client ausgeblendet?

[Brombeermilchtrinker]

Ein 500er wird meistens durch eine fehlerhafte .htaccess verursacht.
Kannst du ausschließen, dass bei dF eine .htaccess in dem Ordner oder einem übergeordneten liegt?

Ja! Ich habe die Testdatei im Rootverzeichnis und ganz sicher keine .htaccess Datei dort!

[Brombeermilchtrinker]

Bei allem verständlichen Unmut gegenüber dF:

Ein Syntax-Fehler z.B. oder ein Abbruch aufgrund zu viel Resourcennutzung liefert ohne entsprechende Konfiguration (wie u.A. display_errors=on - was übrigens bei XAMPP per Default an ist weil XAMPP nicht für Produktivsysteme gedacht ist) natürlich auch einen generischen 500er-Fehler. Das ist absolut korrekt so und auch Standard.
Auch dass du auf die normale php.ini keinen Zugriff hast ist Standard. Genau dafür gibt es seit Jahren bei mod_php die htaccess und bei PHP-FPM und Co die .user.ini: https://www.php.net/manual/de/config...e.per-user.php

Wo die bei dF genau liegt kann ich dir tatsächlich aber auch nicht aus dem Stegreif sagen. Evtl. versteckte Dateien in deinem Client ausgeblendet?

Ich habe jetzt das Verzeichnis in Filezilla mehrmals aktualisiert und mit zeitlicher Verzögerung wird mir seit 1 Minute die .user.ini angezeigt, Wenn ich sie kontrolliere, ist eindeutig display_errors auf ON.
Statt dem 500er kommt somit jetzt die erwartete Meldung. Ich nehme an, in diesen zeitverzögerten 30-60 Minuten ist da noch was aus einem Cache gekommen???

[Brombeermilchtrinker]

Also danke an masterframe und Lukas M. für die Inputs! Mein grundlegendes Problem war, dass mir nicht bewusst gewesen ist, dass Domainfactory das display_errors von Haus aus jetzt auf OFF setzt. Das war nicht immer so. Ich weiß, dass ich viele Jahre lang Warnings und Errors angezeigt bekommen habe, ohne in der .user.ini etwas verändern zu müssen. Deshalb bin ich gar nicht auf die Idee gekommen, dort nachzusehen. Meine Frage ist somit beantwortet und das Thema für mich geschlossen.

[Nils Dornblut]

Hallo Brombeermilchtrinker,

wie die genauen Hintergründe zu der Veränderungen, ich dneke im Rahmen der 64-Bit-Tarife sind, kläre ich intern einmal.

Der 500er-Fehler ist in dem Fall normal und wird hier in einem Kommentar weiter unten auch beschrieben:

https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

Ist dann halt so etwas wie die Motorkontrollleuchte beim Auto.

Aktualisierungen dauern eine kurze Zeit bis sie wirksam werden, das ist richtig und eine Sache des Cache, das ist richtig.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Hallo Brombeermilchtrinker,

wir haben uns das angesehen und meine Antwort bezieht sich auf die 64-Bit-Tarife. Es gäbe auch einige Punkte diesbezüglich zu den alten Tarifen zu sagen, aber das ist bei den auslaufenden Tarifen denke ich weniger relevant.

Grundsätzlich halten wir es für richtig, diese Einstellung nicht auf produktiven Systemen zu aktivieren, da es im Fehlerfall sicherheitsrelevante Ausgaben geben könnte. Dem folgen wir in den PHP-Versionen der 64-Bit-Tarifen auf zwei Weisen:

1. Die von uns genutzten PHP Sourcen stammen hier her https://rpms.remirepo.net/, wie man hier auch sehen kann:
   
   Dort ist die Einstellung anders als bei PHP, wo default auf "ein" für display_errors ist, auf "aus". Das übernehmen wir in den 64-Bit-Tarifen entsprechend.
2. Erzeugt man bei uns via Kundenmenü eine .user.ini setzen wir die Einstellung aus genannten sicherheitstechnischen Abwägungen ebenfalls auf "aus".

Es tut uns leid, dass diese Feinheit so nicht direkt dokumentiert ist, sie geschieht aber in bester Absicht wie ausgeführt. Es ist leider nicht möglich das in diesen Feinheiten übersichtlich darzustellen. Natürlich habe ich das in dieser erweiterten FAQ, wozu wir das Forum zählen, gerne erläutert und hoffentlich verständlich erklärt.

Mit freundlichen Grüßen

Nils Dornblut