Description: ------------ The problem belongs to a combination of HTTP_Request and Net_Socket. HTTP_Request uses Net_Socket::readLine() to be able to read the HTTP response code. On PHP level this is controlled by stream_set_timeout (which is set with the values of readTimeout, from HTTP_Request) which works as it should. The problem is that Net_Socket wraps the call to fgets in a while loop which uses the "timeout" parameter to check how long the while-loop have been running. Which only leads to while-loop running a few more times until the real "timeout" parameter is done. This is also a Net_Socket bug, but it's triggered by missuse? in HTTP_Request. So maybe HTTP_Request needs to take measures of the correct timeout usage as the user shouldn't care about the underlaying classes.

I'd need a test script to see this behaviour first hand before I can do anything here...

Unless this is a duplicate of Bug #7691

(and Bug #7692)

It was a while since the report, I hardly remembers the problem, but it was something like this. Example page to trigger the problem: <?php sleep( 10 ); echo "Hej\n"; ?> Example script to trigger problem: <?php require_once 'HTTP/Request.php'; $req = new HTTP_Request('http://localhost/test.php', array('timeout' => 20, 'readTimeout' => array(8, 0))); if (!PEAR::isError($req->sendRequest())) { echo $req->getResponseBody(); } ?> Here I would expect the script to return error as the 8 is less than the page time out of 10. However, since we specify timeout (connect timeout) to 20, that sorts of overrides the readTimeout setting. With timeout set to 20, script runs successfully for ~10 secs. With timeout set to less than or equal to readTimeout, script return error after 8 secs.

Moving feature requests to HTTP_Request2.

Impemented in CVS. The request will now throw an exception if it takes more seconds than given 'timeout' parameter.