Ankündigung

Einklappen
Keine Ankündigung bisher.

Fehlerabfrage PHP get_headers bzw. get_contents

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • coliflower
    antwortet
    Zitat von jonofe Beitrag anzeigen

    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 ?

    PHP-Code:
    try {
        
    $url 'http://192.168.0.245';
        
    $ch curl_init($url);
        
    curl_setopt($chCURLOPT_RETURNTRANSFERtrue);
        
    curl_setopt($chCURLOPT_TIMEOUT1);
        
    $result curl_exec($ch);
        if (!
    $result) throw new Exception(curl_error($ch));  
    } catch (
    Exception $e)
    {
        
    writeToTraceLog('Exception: '.$e->getMessage());

    Einen Kommentar schreiben:


  • rdeckard
    antwortet
    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.)

    Einen Kommentar schreiben:


  • coliflower
    antwortet
    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 !!

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von coliflower Beitrag anzeigen

    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 <==

    Zitat von coliflower Beitrag anzeigen
    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é

    Einen Kommentar schreiben:


  • coliflower
    antwortet
    Zitat von vento66 Beitrag anzeigen
    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 ...

    PHP-Code:
    try {
        
    $url 'http://192.168.0.245';
        
    $ch curl_init($url);
        
    curl_setopt($chCURLOPT_RETURNTRANSFERtrue);
        
    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());

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • coliflower
    antwortet
    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 ....
    Zuletzt geändert von coliflower; 15.04.2016, 14:06.

    Einen Kommentar schreiben:


  • coliflower
    antwortet
    Zitat von rdeckard Beitrag anzeigen
    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 ...

    PHP-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)

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von rdeckard Beitrag anzeigen
    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

    PHP-Code:
    count($array); 
    insbesondere wenn das Array mit Zahlen beginnend bei 0 indiziert ist oder

    PHP-Code:
    if (array_key_exists($key)) ... 
    um zu prüfen ob ein index überhaupt existiert bevor man drauf zugreift oder

    PHP-Code:
    foreach ($array as $index => $value) { ... } 
    um einfach alle Elemente zu durchlaufen.
    Damit sollten sich Zugriffe auf ungültige Bereiche eigentlich vermeiden lassen.

    VG
    André
    Zuletzt geändert von jonofe; 15.04.2016, 13:38.

    Einen Kommentar schreiben:


  • rdeckard
    antwortet
    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.

    Einen Kommentar schreiben:


  • rdeckard
    antwortet
    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.)

    PHP-Code:

    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($domainFILTER_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 ($chCURLOPT_URL,$url );
      
    curl_setopt($chCURLOPT_USERAGENT$agent);
      
    curl_setopt ($chCURLOPT_RETURNTRANSFER1);
      
    curl_setopt ($ch,CURLOPT_VERBOSE,false);
      
    curl_setopt($chCURLOPT_TIMEOUT5);
      
    curl_setopt($ch,CURLOPT_SSL_VERIFYPEERFALSE);
      
    curl_setopt($ch,CURLOPT_SSLVERSION,3);
      
    curl_setopt($ch,CURLOPT_SSL_VERIFYHOSTFALSE);
      
    $page=curl_exec($ch);
      
    //echo curl_error($ch);
      
    $httpcode curl_getinfo($chCURLINFO_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).

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von rdeckard Beitrag anzeigen
    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:

    PHP-Code:

    try {
        
    $url 'http://192.168.0.245';
        
    $ch curl_init($url);
        
    curl_setopt($chCURLOPT_RETURNTRANSFERtrue);
        
    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.

    Einen Kommentar schreiben:


  • rdeckard
    antwortet
    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...)

    Einen Kommentar schreiben:


  • rdeckard
    antwortet
    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

    PHP-Code:
    $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.

    Einen Kommentar schreiben:


  • gaert
    antwortet
    Zitat von rdeckard Beitrag anzeigen
    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.

    Einen Kommentar schreiben:

Lädt...
X