HTTP Status 'Fehlerhafte Konfiguration'

[hotti]

s. Thema,

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

MfG

[dedlfix]

Tach!

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

500. Was interesiert den Abfragenden die genaue Ursache? Die kommt nur ins Log.

dedlfix.

[hotti]

Tach!

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

500. Was interesiert den Abfragenden die genaue Ursache? Die kommt nur ins Log.

500 heißt, dass der Webserver streikt. Das muss er aber nicht zwangläufig dann machen, wenn z.B. ein CGI-Script, was im Multi-Domain-Betrieb arbeitet, bspw. nur für die Domäne example.com falsch konfiguriert wurde und example.org noch erreichbar ist.

UserAgents, die Test machen, interessieren sich für sowas, bzw. ein nachgelagerter Eskalationsprozess (Stichwort: Zuständigkeiten).

MfG

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

500 heißt, dass der Webserver streikt.

Wenn der Webserver streikt, wie kann er dann noch antworten? ;-D

Spirituelle Grüße
Euer Robert

[dedlfix]

Tach!

500 heißt, dass der Webserver streikt. Das muss er aber nicht zwangläufig dann machen, wenn z.B. ein CGI-Script, was im Multi-Domain-Betrieb arbeitet, bspw. nur für die Domäne example.com falsch konfiguriert wurde und example.org noch erreichbar ist.

Die Gründe, warum der Webserver trotz korrekter Anfrage wegen eines Fehlers nicht das gewünschte Ergebnis liefern kann sind so vielfältig wie uninteressant für den Anfragenden. Solche Fehler sind üblicherweise ungewünscht und der Betreiber wird sie schnellstmöglich korrigiert sehen wollen.

UserAgents, die Test machen, interessieren sich für sowas, bzw. ein nachgelagerter Eskalationsprozess (Stichwort: Zuständigkeiten).

Die Abwägung, ob man interne Informationen weltweit veröffentlicht oder einem solchen Tester Informationen zur Verfügung stellt, würde bei mir zugunsten der Verschwiegenheit ausfallen. Danach wäre die Frage zu klären, ob es sinnvoll ist, einen Tester derart laufen zu lassen und ob er wirklich die genaue Ursache wissen muss, wenn der Administrator sowieso in die Spur muss und selbst nachschauen kann.

dedlfix.

[tinita]

500 heißt, dass der Webserver streikt.

500 Internal Server Error heisst, dass es einen internen Fehler auf dem Server gab. Sehr generisch. Kann ein Konfigurationsfehler des Webservers sein, des Skripts oder irgendwas anderes.
Wenn deine Interpretation da anders ist, musst du dir halt was anderes überlegen.

[Auge]

Hallo

500 heißt, dass der Webserver streikt.

500 Internal Server Error heisst, dass es einen internen Fehler auf dem Server gab. Sehr generisch. Kann ein Konfigurationsfehler des Webservers sein, des Skripts oder irgendwas anderes.

Eben. Nach meinen Erfahrungen ist das gerne mal (sprich: fast immer) ein Skript und nicht der Webserver als solcher.

Wenn deine Interpretation da anders ist, musst du dir halt was anderes überlegen.

Hotti hat in vielerlei Hinsicht sehr eigene Interpretationen.

Davon abgesehen stelle ich mir die Frage, ob eine Misskonfiguration eines auf einem Webserver ausgeführten Skripts eine HTTP-Statusmeldung auslösen darf oder soll.

Tschö, Auge

[dedlfix]

Tach!

Davon abgesehen stelle ich mir die Frage, ob eine Misskonfiguration eines auf einem Webserver ausgeführten Skripts eine HTTP-Statusmeldung auslösen darf oder soll.

Was sonst, wenn die eigentlich gewünschte Antwort nicht erzeugbar ist?

dedlfix.

[Auge]

Hallo

Davon abgesehen stelle ich mir die Frage, ob eine Misskonfiguration eines auf einem Webserver ausgeführten Skripts eine HTTP-Statusmeldung auslösen darf oder soll.

Was sonst, wenn die eigentlich gewünschte Antwort nicht erzeugbar ist?

Ähhm, unter einer Miss- oder Fehlkonfiguration eines Skripts stelle ich mir falsch oder nicht gesetzte Systemvariablen [1] vor. Ein dadurch ausgelöster Fehler hat, außer das Skript reißt den Interpreter mit in's Verderben, was typischerweise einen 500-er auslöst, mMn intern im Programm behandelt zu werden und nicht auf Webserverebene. Auf die Idee, einen HTTP-Status zu senden, weil in einem Skript ein Datenbankfehler auftritt, kommt ja auch niemand, oder?

Ansonsten stellen sich mir die gleichen Fragen wie Chris. Wie stellt man fest, dass eine Konfiguration fehlerhaft ist? Bei einem fehlenden Konfigurationswert geht das natürlich, aber wie macht man das zuverlässig bei einem evtl. falsch gesetzten Wert? Wer legt das „Falsch“ für alle möglichen Konfigurationen und Einsatzszenarien eines Skripts fest?

[1] System meint hier das Programm.

Tschö, Auge

[ChrisB]

Hi,

Auf die Idee, einen [Fehler-]HTTP-Status zu senden, weil in einem Skript ein Datenbankfehler auftritt, kommt ja auch niemand, oder?

Doch, wieso denn nicht?

Wenn ich lediglich einen 200er sende, obwohl bspw. die Datenbank down ist oder weil ein anders gearteter Fehler mit einer Abfrage auftrat – dann ist der Request u.U. gerade der gewesen, mit dem der Suchmaschinen-Bot die Seite crawlen wollte. Will ich den jetzt eine „leere“ Seite in den Index aufnehmen lassen, wo eigentlich die Produktliste eines Online-Shop oder vergleichbares zu sehen gewesen sein sollte?

Natürlich nicht. Also gibt’s entweder einen 500er, oder vielleicht besser sogar noch einen 503 Service Unavailable – und letzteren zusammen mit einem Retry-After (mit einer Zeitspanne, in der der Admin unter normalen Umständen reagiert haben können sollte, um das Problem behoben zu haben).

MfG ChrisB

[Auge]

Hallo

Auf die Idee, einen [Fehler-]HTTP-Status zu senden, weil in einem Skript ein Datenbankfehler auftritt, kommt ja auch niemand, oder?

Doch, wieso denn nicht?

Wenn ich lediglich einen 200er sende, obwohl bspw. die Datenbank down ist oder weil ein anders gearteter Fehler mit einer Abfrage auftrat – dann ist der Request u.U. gerade der gewesen, mit dem der Suchmaschinen-Bot die Seite crawlen wollte. Will ich den jetzt eine „leere“ Seite in den Index aufnehmen lassen, wo eigentlich die Produktliste eines Online-Shop oder vergleichbares zu sehen gewesen sein sollte?

Natürlich nicht. Also gibt’s entweder einen 500er, oder vielleicht besser sogar noch einen 503 Service Unavailable – und letzteren zusammen mit einem Retry-After (mit einer Zeitspanne, in der der Admin unter normalen Umständen reagiert haben können sollte, um das Problem behoben zu haben).

Schon klar, aber diese Statuscodes sind „Allgemeinplätze“. Die vermelden vollkommen zu recht, *dass* ein Fehler aufgetreten ist, aber nicht, welcher. Wenn ich Hotti nicht fehlinterpretiere, ist letzteres das, was er haben möchte und dazu sind die HTTP-Statuscodes mMn nicht da.

Tschö, Auge

[ChrisB]

Hi,

Schon klar, aber diese Statuscodes sind „Allgemeinplätze“. Die vermelden vollkommen zu recht, *dass* ein Fehler aufgetreten ist, aber nicht, welcher. Wenn ich Hotti nicht fehlinterpretiere, ist letzteres das, was er haben möchte und dazu sind die HTTP-Statuscodes mMn nicht da.

Ja, in der Hinsicht gebe ich dir natürlich vollkommen Recht.

MfG ChrisB

[hotti]

Hallo

Ansonsten stellen sich mir die gleichen Fragen wie Chris. Wie stellt man fest, dass eine Konfiguration fehlerhaft ist?

Mit einer zweckmäßigen Fehlerbehandlung bereits in der Entwicklungsphase (Klugscheißermodus *G).

Bei einem fehlenden Konfigurationswert geht das natürlich, aber wie macht man das zuverlässig bei einem evtl. falsch gesetzten Wert?

Die Frage im Allgemeinen beantwortet: Schwierig bis Aufwändig.

Einer der spezielleren Fälle: Es wurde das falsche Template konfiguriert mit der Folge, dass es nicht zur Anwendung passt, Letztere im Browser nicht funktioniert und im schlimmsten Fall Mist macht.

Hier muss die Anwendung selbst getestet werden unter Einbeziehung der Template-Engine.

Ein anderer Fall, Security betreffend: Falsches Template-Verzeichnis konfiguriert, Benutzer im public-Realm sehen Dokumente der Geschäftsleitung. Bestenfalls wird das Template nicht gefunden, aber: Darf nicht passieren, Lösung: Template-Verzeichnis mit dem Realm fest verdrahten....

Wer legt das „Falsch“ für alle möglichen Konfigurationen und Einsatzszenarien eines Skripts fest?

... auf jeden Fall trägt auch hier der Entwickler eine gewisse Verantwortung bei.

Schöne Grüße.

[hotti]

hi,

Davon abgesehen stelle ich mir die Frage, ob eine Misskonfiguration eines auf einem Webserver ausgeführten Skripts eine HTTP-Statusmeldung auslösen darf oder soll.

Genau das ist die Frage ;)

[ChrisB]

Hi,

Wenn deine Interpretation da anders ist, musst du dir halt was anderes überlegen.

Hotti hat in vielerlei Hinsicht sehr eigene Interpretationen.

Wenn Hotti ein Webserver wäre, sollte er generell mit Statuscode 418 antworten …

MfG ChrisB

[Mitleser]

Wenn Hotti ein Webserver wäre, sollte er generell mit Statuscode 418 antworten …

Den musste ich gerade erst nachschlagen. LOL

[Auge]

Hallo

Wenn deine Interpretation da anders ist, musst du dir halt was anderes überlegen.

Hotti hat in vielerlei Hinsicht sehr eigene Interpretationen.

Wenn Hotti ein Webserver wäre, sollte er generell mit Statuscode 418 antworten …

Hyper Text Coffee Pot Control Protocol, soso :-)

Tschö, Auge

[hotti]

Hi,

Wenn deine Interpretation da anders ist, musst du dir halt was anderes überlegen.

Hotti hat in vielerlei Hinsicht sehr eigene Interpretationen.

Wenn Hotti ein Webserver wäre, sollte er generell mit Statuscode 418 antworten …

Sehe ich auch so, weil Fehler der 4xx Gruppe bedeuten:
Die Ursache des Scheiterns der Anfrage liegt im Verantwortungsbereich des Clients.

&SCNR;

[ChrisB]

Hi,

500. Was interesiert den Abfragenden die genaue Ursache? Die kommt nur ins Log.

500 heißt, dass der Webserver streikt. Das muss er aber nicht zwangläufig dann machen, wenn z.B. ein CGI-Script, was im Multi-Domain-Betrieb arbeitet, bspw. nur für die Domäne example.com falsch konfiguriert wurde und example.org noch erreichbar ist.

Das ist immer noch ein interner (Konfigurations-)Fehler.

UserAgents, die Test machen, interessieren sich für sowas, bzw. ein nachgelagerter Eskalationsprozess (Stichwort: Zuständigkeiten).

Wenn du willst, kannst du denen ja mehr Informationen über Art/Ursache des Fehlers mitgeben – entweder in Textform (der Text-Teil eines HTTP-Status-Headers nach dem Status-Code ist schließlich frei wählbar, du darfst als gerne "500 Hotti Fucked Up" senden), oder über zusätzliche X-Header ("X-Error-Caused-By: Misconfiguration of foo") – wobei hier dann natürlich die Frage bleibt, wie du das überhaupt feststellen willst, dass ein Script auf Grund einer fehlerhaften Konfiguration nicht arbeitet.

Allerdings sollte dem Status-Text keinerlei Bedeutung beigemessen werden – jegliche Übertragung von Fehlerinformation darüber müsste also zwischen Server und Client abseits von HTTP vereinbart worden sein.

Und ob du diese Info überhaupt nach draußen geben willst/solltest, wäre auch noch zu überlegen.
Ein externer Dienst, der einen Service auf „läuft“ prüft, muss das eigentlich nicht wissen. Deine „Zuständigkeiten“ sollten auf der inneren Seite der Firmentür geklärt werden, nicht bereits außerhalb.

MfG ChrisB

[hotti]

Hi,

Wenn du willst, kannst du denen ja mehr Informationen über Art/Ursache des Fehlers mitgeben – entweder in Textform (der Text-Teil eines HTTP-Status-Headers nach dem Status-Code ist schließlich frei wählbar, du darfst als gerne "500 Hotti Fucked Up" senden), oder über zusätzliche X-Header ("X-Error-Caused-By: Misconfiguration of foo") – wobei hier dann natürlich die Frage bleibt, wie du das überhaupt feststellen willst, dass ein Script auf Grund einer fehlerhaften Konfiguration nicht arbeitet.

Dass wir noch ein paar weitere Informationen (X-Header) für einen nachgelagerten Escalationsprozess brauchen, ist klar.

Allerdings sollte dem Status-Text keinerlei Bedeutung beigemessen werden

Den Status-Text überlasse ich sowieso dem Server (ob der bei Status: 418 ein unused oder blah drangängt, ist mir egal). Nun, da die HTTP-Spec. für Konfigurationsfehler keinen speziellen Status vorsieht, stehe ich vor der Wahl: 500 oder 200

Eine fehlerhafte Konfig.: Z.B. hat ein Kollege vergessen das Template hochzuladen. Selbstverständlich wird das beim Request festgestellt, aber deswegen stirbt das Script nicht, es ergibt sich ein Status 200 (so ist das bisher).

– jegliche Übertragung von Fehlerinformation darüber müsste also zwischen Server und Client abseits von HTTP vereinbart worden sein.

Warum die Header nicht nutzen, Du schreibst das ja selbst.... s.w.o.

Und ob du diese Info überhaupt nach draußen geben willst/solltest, wäre auch noch zu überlegen.

Wenn sich ein Konfigurationsfehler eingeschlichen hat, sieht das jeder der schneller auf der Seite ist, als derjenige der prüft. Wir geben der Response mit:
Im Header => X-Class: TemplateFile
Im Body   => "Template nicht gefunden"

Das kann jeder sehen, der Besucher kann mit dem Namen der Klasse nichts anfangen (falls der in die Header guckt) und für denjenigen, der dafür zuständig ist, reichen diese Informationen (nur der Eskalationsmanager muss ein bischen mehr wissen).

Ein externer Dienst, der einen Service auf „läuft“ prüft, muss das eigentlich nicht wissen. Deine „Zuständigkeiten“ sollten auf der inneren Seite der Firmentür geklärt werden, nicht bereits außerhalb.

Bei Status: 500 wird gewöhnlich der Administrator aus seinen Träumen gerissen ;)

Schöne Grüße ;)

[ChrisB]

Hi,

Bei Status: 500 wird gewöhnlich der Administrator aus seinen Träumen gerissen ;)

Eben. Und der kann dann im Logfile der Applikation oder des Servers nachschauen, was genau schief gegangen ist – das brauchen wir also gar nicht in alle Welt herausposaunen.

MfG ChrisB

[hotti]

Hi,

Bei Status: 500 wird gewöhnlich der Administrator aus seinen Träumen gerissen ;)

Eben. Und der kann dann im Logfile der Applikation oder des Servers nachschauen, was genau schief gegangen ist – das brauchen wir also gar nicht in alle Welt herausposaunen.

Siehe auch Diese Antwort

[ChrisB]

Hi,

Bei Status: 500 wird gewöhnlich der Administrator aus seinen Träumen gerissen ;)

Eben. Und der kann dann im Logfile der Applikation oder des Servers nachschauen, was genau schief gegangen ist – das brauchen wir also gar nicht in alle Welt herausposaunen.

Siehe auch Diese Antwort

Überhaupt kein Paradoxon – sondern nur mal wieder Hotti nicht in der Lage, den Sinn des geschriebenen Wortes auch vollständig zu erfassen.

Dazwischen, einem Client über den definierten Mechanismus Bescheid zu geben, *dass* etwas schief gegangen ist, und die *Ursache* des Fehlers öffentlich zu machen, besteht ein fundamentaler Unterschied.

Aber diese Diskussion gleich wieder mal so vielen vor ihr, die von dir angestoßen wurden – im Versuch, alles über-korrekt zu handhaben, verläufst du dich auf Irrwege. Alles nichts neues, sondern – leider – altbekannt.

MfG ChrisB

[hotti]

Hi,

Bei Status: 500 wird gewöhnlich der Administrator aus seinen Träumen gerissen ;)

Eben. Und der kann dann im Logfile der Applikation oder des Servers nachschauen, was genau schief gegangen ist – das brauchen wir also gar nicht in alle Welt herausposaunen.

Siehe auch Diese Antwort

Überhaupt kein Paradoxon – sondern nur mal wieder Hotti nicht in der Lage, den Sinn des geschriebenen Wortes auch vollständig zu erfassen.

Ja, was meinst Du denn nun wirklich: Bei Konfigurationsfehler einen Status 500 senden oder einen Status 200?

Ganz oben schreibst Du: .... nicht in alle Welt herausposaunen.
Unter dem Link schreibst Du (als Antwort auf die Frage nach einem Fehlerstatus): Doch, wieso denn nicht?

Also was nun?

MfG

[bubble]

Ganz oben schreibst Du: .... nicht in alle Welt herausposaunen.
Unter dem Link schreibst Du (als Antwort auf die Frage nach einem Fehlerstatus): Doch, wieso denn nicht?

Also was nun?

Es war ja verlinkt, aber auf das Relevante nimmst du auch keinen Bezug.

Wenn ich lediglich einen 200er sende, obwohl ...

Natürlich nicht. Also gibt’s entweder einen 500er, oder vielleicht besser sogar noch einen 503 Service Unavailable

Wenn irgendwas systematisch (durch Konfigurations-/Programmfehler) nich läuft 500, wenn etwas durch temporäre Unerreichbarkeit (z.B. ein Dienst eines Drittanbieters, oder der gleichen nicht erreichbar ist) 503 ...

Aber ein 200er sagt aus "alles is okay, das was du bekommst is dat wat du wolltest", was bei der Diskussionsgrundlage einfach nich der Fall ist.

MfG
bubble

[ChrisB]

Hi,

Ganz oben schreibst Du: .... nicht in alle Welt herausposaunen.
Unter dem Link schreibst Du (als Antwort auf die Frage nach einem Fehlerstatus): Doch, wieso denn nicht?

Fehler*status*, ja. Begreifst du nicht, dass das etwas anderes ist, als die Fehler*ursache* öffentlich zu machen … oder willst du nur wieder mal nicht?

MfG ChrisB

[Camping_RIDER]

Aloha ;)

*hüstel* *flüster*

oder willst du nur wieder mal nicht?

Bitte nicht persönlich werden. Auch wenn ich's verstehen kann, dass einem Dinge manchmal auf den Wecker gehen. Nicht als Angriff zu verstehen, nur als Hinweis... Wir wollen doch nicht, dass hier jemand angekratzt rausgeht...

Grüße,

RIDER

[hotti]

s. Thema,

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

Ich habe mich nun dazu entschieden, einen Status: 502 zu senden, weil eine fehlerhafte Konfiguration in Fakt den Gateway betrifft und nicht den Server.

Ein automatischer Test läuft dann so ab:

1. mein Bot requested die aktuell auf dem Produktivsystem vorliegende Konfiguration, er bekommt in der Response für jeden Unterseite-URL auch den Namen der dafür zuständigen Subklasse, letzteres ist ja wichtig für den Rapport. Und nein, er bekommt das alles NICHT in XML und auch nicht als JSON ;)

2. mein Bot macht dann für jeden URL einen HEAD-Request und wertet nur den Status aus.

Das sollte fürs Erste reichen.

Schönes Wochenende.

[Sven Rautenberg]

Moin!

s. Thema,

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

Ich habe mich nun dazu entschieden, einen Status: 502 zu senden, weil eine fehlerhafte Konfiguration in Fakt den Gateway betrifft und nicht den Server.

Das heißt, dein Server, der Status 502 senden, hat seinerseits einen HTTP-Request an jemand anderes gesendet und mangelhaft beantwortet bekommen.

- Sven Rautenberg

[hotti]

Moin!

s. Thema,

welchen Status könnten wir denn da senden, wenn z.B. die serverseitig eingesetzte Software (nicht der Apache, sondern bspw. ein CGI-Script) fehlerhaft konfiguriert wurde?

Ich habe mich nun dazu entschieden, einen Status: 502 zu senden, weil eine fehlerhafte Konfiguration in Fakt den Gateway betrifft und nicht den Server.

Das heißt, dein Server, der Status 502 senden, hat seinerseits einen HTTP-Request an jemand anderes gesendet und mangelhaft beantwortet bekommen.

Der Begriff Gateway bezieht sich nicht unbedingt auf einen HTTP-Request. Apache-Webserver meldet Gateway-Fehler-Codes u.a. auch bei Fehlern über die CGI-Schnittstelle, z.B., wenn ein CGI-Script nicht innerhalb einer bestimmten Zeit geantwortet hat (Gateway-Timeout, Statuscode 504). Lt. CGI/1.1 kommuniziert der Apache mit einem CGI-Script über die StandardHandle STDIN, STDOUT. Status: 502 Bad Gateway => Das CGI-Script hat ne Macke.

435 URLs mal eben gestestet:

D:>c.pl BOT
Teste die Konfiguration meiner WebSite,
zeigt alles, was nicht Status 200 sendet
--loc, -l: de oder lo

D:>c.pl BOT  -l de
URL           => Class    => Code
/attach.html  => NotFound => 404
/binhtml.html => NotFound => 404

Aus gegebenem Anlass ;)

Schönes Wochenende.