HTTPRequest - Timeout funktioniert nicht die 2.

  • Vor etwas mehr als einem Jahr hatte ich bereits das gleiche Problem gemeldet: HTTPRequest - Timeout funktioniert nicht - Erledigt - WoltLab®


    Der Fehler wurde zwar gelöst, allerdings scheint es noch ein anderes Symptom dieser Art zu geben:



    Das Problem ist schon seit Jahren durch eine unserer Erweiterungen bekannt, ließ sich bisher aber nie zuverlässig reproduzieren, bis zur heutigen Meldung von PoooMukkel und Cyperghost.


    Nachtrag: Das Problem ist RequestOptions::TIMEOUT => 0, in HTTPRequest:193. Setze ich $this->options['timeout'] statt der 0, funktioniert es wie erwartet.


    Nachtrag #2: Mir ist natürlich bewusst, dass HTTPRequest veraltet ist, allerdings ist das Plugin seit je her mit WSC 3.0+ kompatibel und bisher noch nicht exklusiv für 5.2+ erschienen.

  • Wovon? Vom WSC? Aktuell nutze ich die Version 5.4.8. Das Problem trat aber bereits im WSC 5.3 auf. Nur scheint es jetzt seit WSC 5.4 noch mehr aufzutreten.

    • Official Post

    Hallo,


    kann ich (in einem aktuellen 5.5 – Änderungen gab es diesbezüglich seit 5.4 keine) nicht reproduzieren. Das Script aus dem Startbeitrag funktioniert bei mir problemlos und innerhalb von etwa einer halben Sekunde.


    • Official Post

    Hallo,


    für mich auch mit deaktiviertem cURL nicht reproduzierbar (die Seite lädt einwandfrei).


    In HTTPRequest setzen wir einen Connect-Timeout und einen Read-Timeout. Letzterer setzt ein Limit auf den Zeitraum bis neue Bytes vom Server kommen müssen. Wenn die nicht funktionieren, dann ist die PHP-Installation defekt.


    Unabhängig davon kann ich die Umstellung auf Guzzle natürlich empfehlen. Alle WoltLab Suite-Versionen ohne Guzzle sind am Ende des Jahres EoL.

  • Denke mal damit ist gemeint, das es nicht an WBB liegt sondern entweder wie geschrieben an der PHP Installation oder das man statt dessen Guzzle verwenden soll.

  • Tim Düsterhus


    Wie bereits erwähnt, funktioniert es nach Änderung des 0-Wertes in der HTTPRequest-Klasse auch wie erwartet.


    Dazu sei auch gesagt, dass das auf Hetzner-Servern getestet wurde, die von der betreffenden Seite vermutlich blockiert wurden.

  • Denke mal damit ist gemeint, das es nicht an WBB liegt sondern entweder wie geschrieben an der PHP Installation oder das man statt dessen Guzzle verwenden soll.

    Dass es an der PHP Installation liegt, schließe ich aus. Ich denke Cyperghost als mein Hoster weiß, was er tut. 😉


    Das Problem tritt übrigens sowohl unter PHP 7 als auch 8 auf.

  • Dass es an der PHP Installation liegt, schließe ich aus. Ich denke Cyperghost als mein Hoster weiß, was er tut. 😉


    Das Problem tritt übrigens sowohl unter PHP 7 als auch 8 auf.


    Das Problem tritt vor allem auch in mindestens zwei vollkommen voneinander unabhängigen Installationen auf zwei voneinander vollkommen unabhängigen Servern auf. Ich wage zu bezweifeln, dass auf beiden Servern dieselbe Fehlkonfiguration vorliegt ;)

  • Das Problem ist RequestOptions::TIMEOUT => 0, in HTTPRequest:193. Setze ich $this->options['timeout'] statt der 0, funktioniert es wie erwartet.

    Habe die Änderung eingebaut und es funktioniert! Schade, dass diese Änderung nicht update-sicher ist... :/

  • Ich kann dieses Verhalten bei mir ebenfalls mit wget reproduzieren. Wget wartet einfach bis zum abwinken und endet nie. Curl hingegen kann einfach nach ein paar ms mit den http 403 geben. Ich vermute jedoch ganz stark das es sich unteranderem um eine Art bot Schutz von cyberport handelt. Jedoch er gibt es für mich keinen Sinn, warum der Php timeout nicht Greift sowohl auf Debian, suse und anderen Betriebssysteme. Der php Pool Prozess ist immer noch aktiv und wird nicht beendet egal ob der timeout erreicht ist oder nicht und wird als aktiv angezeigt. Mit curl hingegen auf php Basis sowie Shell tritt dieses Verhalten nicht auf. Daher vermute ich ganz stark das dort irgendetwas ist, was in einer Art while Schleife hängen bleibt. Was beide Implementierungen identisch haben ;)

    • Official Post

    Hallo,

    Habe die Änderung eingebaut und es funktioniert! Schade, dass diese Änderung nicht update-sicher ist... :/

    ich rate davon ab, irgendwelche Änderungen vorzunehmen die man nicht versteht, nur weil sie auf den ersten Blick irgendetwas zu korrigieren scheinen. Das wurde mit WoltLab Suite 5.3.2 nämlich bewusst angepasst, weil die Verwendung des TIMEOUT-Werts Fehler verursacht hat:


    Replace HTTPRequest's timeout by connect_timeout + read_timeout · WoltLab/WCF@2dbd565
    The timeout in 5.2 only applied to the connect() syscall. Guzzle's timeout option applies to the total transfer. Replace it by connect_timeout +…
    github.com


    Das habe ich weiter oben aber auch bereits gesagt: Die Timeouts sind genau so gesetzt wie sie gesetzt werden müssen. Wenn der read-Timeout nicht greift, dann ist entweder die PHP-Installation kaputt, oder der entfernte Server sendet noch Daten.

    Der php Pool Prozess ist immer noch aktiv und wird nicht beendet egal ob der timeout erreicht ist oder nicht und wird als aktiv angezeigt.

    Dann empfehle ich nachzusehen was der Prozess überhaupt macht.

    • Official Post

    Hallo,

    Curl hingegen kann einfach nach ein paar ms mit den http 403 geben.

    ich habe außerhalb dieses Thema noch einen Tipp bekommen:


    Das betrifft offenbar nur HTTP/1.1-Verbindungen. Mit:

    Code
    curl -v 'https://www.cyberport.de/pc-und-zubehoer/netzwerk/router/asus/pdp/5615-047/asus-rt-ac88u-dualband-wireless-ac3100-gigabit-ac-router-90ig01z0-bm3000.html' --http1.1

    kann ich es auch lokal reproduzieren (in meiner Installation noch immer nicht).


    Mit:

    Code
    curl -v 'https://www.cyberport.de/pc-und-zubehoer/netzwerk/router/asus/pdp/5615-047/asus-rt-ac88u-dualband-wireless-ac3100-gigabit-ac-router-90ig01z0-bm3000.html' --http2.0

    funktioniert es.

    • Official Post

    Hallo,


    könnt ihr (zwangsläufig ungetestet) mal folgendes probieren:

  • Tim Düsterhus das verursacht kein Fehler.

    Wenn ich wget2 mache, geht dies ebenfalls. Da machen die aber was sehr komisches auf der Seite das dies zu so einem Fehler kommt.

    Dann empfehle ich nachzusehen was der Prozess überhaupt macht.

    Leider kann ich aktuell nicht auf unseren Kunden-Server das machen, aber solltest du das genau wissen wollen kann ich dies gerne auf einem Separaten Test-Server machen. Der Prozess war im Running State ;) Das ist das einzige was ich aktuell sagen könnte.