Fehlerabfrage PHP get_headers bzw. get_contents

[coliflower]

Nein eigentlich nicht. Außer man sollte vielleicht schauen, welche hilfreichen Optionen es noch für curl gibt: ==> HIER <==


Es ist grundsätzlich zu empfehlen ein Error Handling einzubauen, nicht nur bei Webserver Zugriffen.
Noch besser ist es, eine gute Validierung der Eingangsparameter zu machen, damit Errors/Exceptions soweit wie möglich vermieden werden.

VG
André

Nochnmals danke André !

Ja, die Eingangsparameter frage ich soweit möglich ab, ob vorhanden und ob diese auch plausibel sind :-)

die cURL würde ich noch gern um die curl_close($ch) (close cURL resource, and free up system resources) falls das Sinn macht ?
Danach würde ich gerne deinen Code-Vorschlag immer dann wenn ich den WebServer abfrage, verwenden :-)

Leider bin im mir nicht sicher ob ich die curl_close() zwischen $result und IF einbauen muss, quasis nach curl_exec() wie es in den Standardbeispielen gezeigt wird oder erst nach "IF" wie in diesem Beispiel ?

Auch kann ich nicht einschätzen ob - THEORETISCH - eine sekündliche Abfrage hier zu irgendwelchen Problemen führen kann ?

try {
    $url = 'http://192.168.0.245';
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_TIMEOUT, 1);
    $result = curl_exec($ch);
    if (!$result) throw new Exception(curl_error($ch));  
} catch (Exception $e)
{
    writeToTraceLog('Exception: '.$e->getMessage());
} 

[rdeckard]

Ja, Error Handling ist immer wichtig. Das ist es schliesslich, was am Ende ein Programm stabil oder halt nicht stabil macht. Unvorhergesehene Fehler können immer auftreten. Man muss sie nur irgendwie abfangen, um einen kontrollierten Abgang zu gewährleisten.

Und gerade bei URL-Zugriffen ist es meist nicht so einfach, wie es am Anfang erscheint. Der Server kann down sein (Physikalisch oder nur der Webserver), da hilft dann ein prüfen des Headers nicht viel (wie ich ja bei mir feststellen musste).
Und wenn man die Headers prüft, dann dran denken, dass es da draussen vieles gibt. Nur auf "HTTP/1.1 404 Not Found" prüfen reicht nicht. Ich hatte schon Fälle, wo "HTTP/1.0 404 Not Found" zurückkam. Oder eben 403 (Forbidden), 405 (Method not allowed) und die ganzen 300er Redirections. (google.com und www.google.com geben u.U. andere Headers zurück).
Also aufpassen und in diesem konkreten Fall nie blind darauf vertrauen. (Ausser das Zielsystem ist fix und das Verhalten bekannt, wie bei mir mit dem Wechselrichter.)

[coliflower]

Es ist grundsätzlich zu empfehlen ein Error Handling einzubauen, nicht nur bei Webserver Zugriffen.

Klar, nachvollziehbar ... WebServer und alles was über das Netzwerk läuft ist - denke ich - noch mal "strenger" zu bewerten ...

Und danke für dein Feedback !!

[jonofe]

Muss man in deinem Code auf noch etwas achten wenn man den WebServar auf UP/DOWN abgragt ?

Nein eigentlich nicht. Außer man sollte vielleicht schauen, welche hilfreichen Optionen es noch für curl gibt: ==> HIER <==

Ich denke diesen Code-Schnipsel sollte man jedes Mal einbauen wenn man auf WebServer zugreift ...

Es ist grundsätzlich zu empfehlen ein Error Handling einzubauen, nicht nur bei Webserver Zugriffen.
Noch besser ist es, eine gute Validierung der Eingangsparameter zu machen, damit Errors/Exceptions soweit wie möglich vermieden werden.

VG
André

[coliflower]

Ja, aber wenn der Server nicht da ist, gibt es kein 404!

Ich gehe davon aus dass du gar kein Url hast wenn sich deine Hardware verabschiedet und du somit die get_headers() in die IF-Abfrage setzten müsstest ... danke ich (sorry, bin kein Programmierer)

OK, wenn das mit IF get_geaders() nicht funkt, dann die CURL-Lösung oben (danke).

jonofe

Muss man in deinem Code auf noch etwas achten wenn man den WebServar auf UP/DOWN abgragt ?
Ich denke diesen Code-Schnipsel sollte man jedes Mal einbauen wenn man auf WebServer zugreift ...

try {
    $url = 'http://192.168.0.245';
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch,CURLOPT_TIMEOUT,1);
    $result = curl_exec($ch);
    if (!$result) throw new Exception(curl_error($ch));  
} catch (Exception $e)
{
    writeToTraceLog('Exception: '.$e->getMessage());
} 

[vento66]

Ja, aber wenn der Server nicht da ist, gibt es kein 404!

[coliflower]

ABER...dieser Nervfaktor zwingt einem auch dazu, dass man das Problem so lösen möchte, dass gar keine Fehler Logs mehr erzeugt werden. Und das ist ja auch immer dein Hintergedanke. Und grundsätzlich unterstütze ich dies auch. (Ein Fehlerlog sollte sauber sein!)

Aber auch dann solltest du dieses mögliche Problem im LBS abfangen, für den Fall ....

[coliflower]

coliflower
Danke, aber ich weiss nicht, wie mir das weiterhelfen kann? Du hast zwar eine etwas andere Abfrage, aber das Grundproblem müsste bei dir auch auftreten. Siehe dein Code in deiner vorherigen Nachricht: https://knx-user-forum.de/forum/proj...360#post929360

Ne sorry, das war dieser Code ...

if ($headers1[0] == 'HTTP/1.1 404 Not Found') {
    $player__ = '{"status":"","time":""}';
    writeToTraceLog(0,true,'404er is TRUE >> EXIT Player');
} else {
    $player__ = file_get_contents('http://'.$E[3]['value'].'/%7E'.$E[5]['value'].'/'.$E[11]['value'].'.json');
    writeToTraceLog(0,true,'404er do not exists / Player '.$player__);
} 

Ich frage hier am WebServer ob eine JSON-Datei liegt oder nicht indem ich den 404er Fehlercode abfrage und wenn die Datei nicht da ist, verwende ICH einen DUMMY-Code ...
Anstatt dess Dummy-Codes kannst du ja eine andere Aktion auslösen ...

Der "$headers1 = get_headers($urlplayer);" ist der Knackpunkt und ausserhalb der if-Abfrage.

Nein, diese Problem habe ich nicht ... Wenn die JSON nicht da ist dann kommt eben der DUMMY zum Einsatz ...
Ich gehe davon aus dass du gar kein Url hast wenn sich deine Hardware verabschiedet und du somit die get_headers() in die IF-Abfrage setzten müsstest ... danke ich (sorry, bin kein Programmierer)

[jonofe]

jonofe
Dort laufe ich ab und zu mal bei einem Array in einen ungültigen Bereich, den ich bis jetzt nicht richtig abfangen konnte und es mir dann natürlich ins Edomi Log zurückschlägt. Ein catch könnte das evtl. abfangen.

Bei arrays hilft auch oft ein

count($array); 

insbesondere wenn das Array mit Zahlen beginnend bei 0 indiziert ist oder

if (array_key_exists($key)) ... 

um zu prüfen ob ein index überhaupt existiert bevor man drauf zugreift oder

foreach ($array as $index => $value) { ... } 

um einfach alle Elemente zu durchlaufen.
Damit sollten sich Zugriffe auf ungültige Bereiche eigentlich vermeiden lassen.

VG
André

[rdeckard]

jonofe
Danke, das mit dem exception gefällt mir. Deine Routine ist schlank und scheint mir sicherer zu sein. (Zumindest für den richtigen Server Down Fall)

Das bringt mich grad noch auf eine andere Idee in einem anderen LBS. Dort laufe ich ab und zu mal bei einem Array in einen ungültigen Bereich, den ich bis jetzt nicht richtig abfangen konnte und es mir dann natürlich ins Edomi Log zurückschlägt. Ein catch könnte das evtl. abfangen.

[rdeckard]

Ich habe jetzt zwei Funktionen gefunden, die in diese Richtung gehen. Problem bei solchen Lösungen ist oft, dass sie nicht bei allen Webservern funktionieren. Es gibt Firmen, die keinen direkten Zugriff auf ihren Webserver mögen und dies dann blockieren, somit würde dies einen False Alarm geben. Dann muss man mit User Agents kommen, damit es wie ein Browser aussieht.

Ich habe die Funktionen mal in mein LBS eingefügt und erfolgreich getestet. In meinem Fall würde schon eine der beiden Funktionen reichen. Wenn man das Zielsystem kennt und Down und Up getestet hat, kann man mit der Funktion arbeiten, die funktioniert.
Ist das Zielsystem jedoch variabel, so muss man u.U. einen grösseren Aufwand betreiben und die Funktionen evtl. ZUSAMMEN verwenden. (Auch dann ist nicht immer 100% sicher, dass es funktioniert.)

if (Visit("http://xxxx"))
       echo "Website OK";
else
       echo "Website DOWN";

//if (isDomainAvailable('http://xxxx'))
//{
//  echo "Website OK";
//}
//else
//{
//  echo "Website DOWN";
//}



function isDomainAvailable($domain)
{
  //check, if a valid url is provided
  if(!filter_var($domain, FILTER_VALIDATE_URL))
  {
    return false;
  }

  //initialize curl
  $curlInit = curl_init($domain);
  curl_setopt($curlInit,CURLOPT_CONNECTTIMEOUT,10);
  curl_setopt($curlInit,CURLOPT_HEADER,true);
  curl_setopt($curlInit,CURLOPT_NOBODY,true);
  curl_setopt($curlInit,CURLOPT_RETURNTRANSFER,true);

  //get answer
  $response = curl_exec($curlInit);

  curl_close($curlInit);

  if ($response) return true;

  return false;
}

function Visit($url){
  $agent = "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)";$ch=curl_init();
  curl_setopt ($ch, CURLOPT_URL,$url );
  curl_setopt($ch, CURLOPT_USERAGENT, $agent);
  curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
  curl_setopt ($ch,CURLOPT_VERBOSE,false);
  curl_setopt($ch, CURLOPT_TIMEOUT, 5);
  curl_setopt($ch,CURLOPT_SSL_VERIFYPEER, FALSE);
  curl_setopt($ch,CURLOPT_SSLVERSION,3);
  curl_setopt($ch,CURLOPT_SSL_VERIFYHOST, FALSE);
  $page=curl_exec($ch);
  //echo curl_error($ch);
  $httpcode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
  curl_close($ch);
  if($httpcode>=200 && $httpcode<400) return true;
  else return false;
} 

Für Edomi LBS muss der Code noch etwas angepasst werden (keine echos).

[jonofe]

Wie kann ich eine URL prüfen, ob sie online ist, ohne schon bei der Prüfung einen PHP-Fehler zu erzeugen?

Ich würde es mit curl machen statt mit get_headers() und zwar vom Prinzip her in etwa so:

try {
    $url = 'http://192.168.0.245';
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch,CURLOPT_TIMEOUT,1);
    $result = curl_exec($ch);
    if (!$result) throw new Exception(curl_error($ch));  
} catch (Exception $e)
{
    echo "Exception: ".$e->getMessage()."\n";
} 

TIMEOUT gibt in Sekunden an, wie lange auf die gewartet werden soll. Wenn erfolgreich kannst du mir $result nach dem catch Bereich weitermachen. Ansonsten kannst du im catch Bereich eine Meldung ins Tracelog schreiben. Dann sollte eigentlich kein Error und keine Warning auftreten.

Aus dem echo() muss dann natürlich ein writeToTraceLog() werden.

[rdeckard]

gaert
Jaja...klar nervt es. Weil ich ja die Ursache des Fehlers kenne und es auch nicht so kritisch ist. Da man nicht einfach das Fehlerlog aus der Edomi Verwaltung löschen kann, muss ich dann mit einem FTP-Programm zuerst das Log löschen. Ist halt alles bisschen mühsam.

ABER...dieser Nervfaktor zwingt einem auch dazu, dass man das Problem so lösen möchte, dass gar keine Fehler Logs mehr erzeugt werden. Und das ist ja auch immer dein Hintergedanke. Und grundsätzlich unterstütze ich dies auch. (Ein Fehlerlog sollte sauber sein!)

Somit kritisiere ich es nicht. Es nervt, ja, aber das liegt eher an meiner Faulheit, den Fehler zu beheben. (Was mich aber immerhin zu diesem Thread geführt hat.)

Wenn mans in Zukunft quittieren kann, bin ich aber auch nicht unglücklich. (Auch wenn dann wieder das Risiko besteht, dass man in Zukunft solche Fehler nicht mehr behebt...)

[rdeckard]

coliflower
Danke, aber ich weiss nicht, wie mir das weiterhelfen kann? Du hast zwar eine etwas andere Abfrage, aber das Grundproblem müsste bei dir auch auftreten. Siehe dein Code in deiner vorherigen Nachricht: https://knx-user-forum.de/forum/proj...360#post929360

$url = 'http://'.$E[3]['value'].'/%7E'.$E[5]['value'].'/';
            
            $urlplayer = $url.$E[11]['value'].'.json';
            $headers1 = get_headers($urlplayer);
            
            if ($headers1[0] == 'HTTP/1.1 404 Not Found') {
                EXIT;
                writeToTraceLog(0,true,'404er is TRUE >> EXIT Player');
            } else {
                $player__ = file_get_contents('http://'.$E[3]['value'].'/%7E'.$E[5]['value'].'/'.$E[11]['value'].'.json');
                writeToTraceLog(0,true,'404er do not exists / Player '.$player__);
            } 

Der "$headers1 = get_headers($urlplayer);" ist der Knackpunkt und ausserhalb der if-Abfrage. Sobald er mit get_headers die Header-Infos auslesen möchte und die URL nicht gefunden wird, stösst er natürlich auf einen Fehler. Und DIESEN Fehler möchte ich abfangen.
Kann sein, dass es bei mir auch nur kommt, weil das Device offline ist und nicht nur einfach die Datei fehlt. Fehlt die Datei, kann der entfernte Webserver ja noch eine Antwort schicken (und diese kann man später dann abfragen). Ist aber der Webserver tot (oder die URL falsch), so kommt natürlich gar nichts zurück. Und dies ist offenbar mein Problem.

[gaert]

Und seit Edomi dies ja in der Visu anzeigt, nervt es stark.

Tja... Ich wollte es ja nicht implementieren - aber einige Nutzer bestanden darauf

Aber keine Sorge: Bald wird man die Meldung quittieren können und dann ist Ruhe.