HTTPRequest - Timeout funktioniert nicht die 2.

SoftCreatR · Sep 27th 2021

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:

PHP

<?php
require __DIR__ . '/global.php';

$start = microtime(true);

try {
    $request = new \wcf\util\HTTPRequest( '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', ['timeout' => 2]);
    $request->execute();
    $reply = $request->getReply();
} catch (\Exception $e) {
    wcfdebug(microtime(true) - $start, $e->getMessage());
}

wcfdebug(microtime(true) - $start, $reply['headers']);

Display More

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.

**Tim Düsterhus** · Sep 27th 2021

Hallo,

welche Version ist im Einsatz?

PoooMukkel · Sep 27th 2021

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.

**Tim Düsterhus** · Sep 27th 2021

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.

Code

Argument 0 (double)
float(0.41253209114074707)
Argument 1 (array)
Array
(
    [Server] => Cyberport
    [Content-Length] => 223164
    [Content-Type] => text/html; charset=UTF-8
    [Set-Cookie] => akaalb_RampDown_Query=~op=RAMPDOWN_Query_String_Parameter_ws30_1:Berlin|~rv=77~m=Berlin:0|~os=a81329898cf16e69bb757ca1bc021ac4~id=d97b0d61605a6c55322f12ea15dd048f; path=/; HttpOnly; Secure; SameSite=None
    [Strict-Transport-Security] => max-age=15768000
    [X-XSS-Protection] => 1; mode=block
    [X-Frame-Options] => sameorigin
    [X-Content-Type-Options] => nosniff
    [Link] => ; rel=preconnect
    [Server-Timing] => cdn-cache; desc=HIT
    [Vary] => Accept-Encoding
    [X-Akamai-Transformed] => 9 133 0 pmb=mTOE,1mRUM,2
    [X-VCache-Debug-edge-control-max-age] => 10080
    [X-VCache-Debug-s-max-age] => 1440
    [X-VCache-Debug-max-age] => 0
    [ETag] => "1618421990:dtagent10223210811140219oSTG:dtagent10223210811140219oSTG:dtagent10223210811140219oSTG"
    [X-OneAgent-JS-Injection] => true
    [X-Debug-Includes-Webserver] => true
    [X-UA-Compatible] => IE=Edge
    [Expires] => Mon, 27 Sep 2021 14:32:42 GMT
    [Cache-Control] => max-age=0, no-cache
    [Pragma] => no-cache
    [Date] => Mon, 27 Sep 2021 14:32:42 GMT
    [Connection] => close
)
wcfDebug() called in /var/www/html/download.php on line 14

Display More

PoooMukkel · Sep 27th 2021

SoftCreatR und Cyperghost können sicher mehr dazu sagen als ich. Ich bin nur Nutzer und seit Monaten von diesem Problem und dessen Auswirkungen genervt.

SoftCreatR · Sep 27th 2021

Getestet habe ich das in 5.4.

**Tim Düsterhus** · Sep 27th 2021

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.

PoooMukkel · Sep 27th 2021

Was bedeutet das Label „umgesetzt“ in diesem Content nun? 🤔

Falki18 · Sep 27th 2021

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.

SoftCreatR · Sep 27th 2021

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.

**Tim Düsterhus** · Sep 27th 2021

Hallo,

Quote from PoooMukkel

Was bedeutet das Label „umgesetzt“ in diesem Content nun? 🤔

dass die Timeouts genau wie gewollt gesetzt werden, insbesondere, dass das Verhalten von HTTPRequest auf Guzzle-Basis dem Verhalten von HTTPRequest vor Guzzle entspricht.

Wäre es als Fehler gemeldet worden, dann wäre es „Nicht reproduzierbar“ bzw. „Funktioniert wie gewollt“.

SoftCreatR · Sep 27th 2021

Quote from Tim Düsterhus

Wäre es als Fehler gemeldet worden, dann wäre es „Nicht reproduzierbar“ bzw. „Funktioniert wie gewollt“.

Da hab ich mich vertan. Sollte natürlich ein Bugreport sein.

PoooMukkel · Sep 27th 2021

Quote from Falki18

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.

SoftCreatR · Sep 27th 2021

Quote from PoooMukkel

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

PoooMukkel · Sep 27th 2021

Quote from SoftCreatR

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

Cyperghost · Sep 27th 2021

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

**Tim Düsterhus** · Sep 28th 2021

Hallo,

Quote from PoooMukkel

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.

Quote from Cyperghost

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.

**Tim Düsterhus** · Sep 28th 2021

Hallo,

Quote from Cyperghost

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.

**Tim Düsterhus** · Sep 28th 2021

Hallo,

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

Diff

diff --git i/wcfsetup/install/files/lib/util/HTTPRequest.class.php w/wcfsetup/install/files/lib/util/HTTPRequest.class.php
index 2e6c0f32d1..8d62f3308c 100644
--- i/wcfsetup/install/files/lib/util/HTTPRequest.class.php
+++ w/wcfsetup/install/files/lib/util/HTTPRequest.class.php
@@ -198,6 +198,11 @@ public function execute()
                 'track_redirects' => true,
                 'on_redirect' => $redirectHandler,
             ],
+            'curl' => [
+                \CURLOPT_TCP_KEEPALIVE => true,
+                \CURLOPT_TCP_KEEPIDLE => 5,
+                \CURLOPT_TCP_KEEPINTVL => 5,
+            ]
         ];
         if (isset($this->options['maxLength'])) {
             $options[RequestOptions::STREAM] = true;

Display More

Cyperghost · Sep 28th 2021

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.

Quote from Tim Düsterhus

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.

HTTPRequest - Timeout funktioniert nicht die 2.

Tim Düsterhus Sep 27th 2021

Tim Düsterhus Sep 27th 2021

Tim Düsterhus Sep 27th 2021

Share

Similar Threads

Rewrite Rules bei Update von 4.x auf 5.x

Timeout Meldung wenn ACP-Session abgelaufen ist

Fehlermeldung bei Upgrade WBB4.1.21 auf WBB5.0.25

Nochmal falsche Links (Google und Links in 5.3 nach Update von 2.3.6)

HTTPRequest - Connect-Timeout wird ignoriert