Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.7.0

Request #5735 No "true" timeout exists
Submitted: 2005-10-20 19:46 UTC
From: seth at pricepages dot org Assigned: avb
Status: Closed Package: HTTP_Request2
PHP Version: 4.4.0 OS: Mac
Roadmaps: 0.2.0    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 42 + 9 = ?

 
 [2005-10-20 19:46 UTC] seth at pricepages dot org
Description: ------------ I'm not sure if this is a bug or a feature request, but although there exists two timeout options in HTTP_Request, it can be delayed indefinitely. This is done by sending a little data at a time. The documentation says: "timeout - Connection timeout in seconds" "readTimeout - Timeout for reading / writing data over the socket" It seems to imply that there is a true way to limit the connection time, but there is not. (Leading to some of my pages taking a 22 seconds to render.) I think that the way to be the most BC would be to make a third timeout option that limits the total time taken (including connection time and redirects). This option could be checked after each socket read. If requested, I could implement this. Test script: --------------- test.php: <?php require_once('PEAR.php'); require_once('HTTP/Request.php'); $url = 'http://pricepages.org/pear/slow_page.php'; $req = new HTTP_Request($url, array( 'timeout' => 2, 'readTimeout' => array(2,0))); $req->sendRequest(); ?> slow_page.php: <?php sleep(1); ob_end_flush(); for($i = 0; $i < 100; $i++){ echo "a big block of text, just rendered "; flush(); usleep(100000); } ?> Expected result: ---------------- $ time php -f test.php real 0m2.000s user 0m0.085s sys 0m0.059s Actual result: -------------- $ time php -f test.php real 0m12.258s user 0m0.085s sys 0m0.059s

Comments

 [2005-11-06 18:38 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2005-11-08 05:17 UTC] seth at pricepages dot org
Would the best way to do this be to readAll() from the socket in non-blocking mode and then after each read, check the utime? (That is the best I can think of.) There would also need to be another option passed into the constructor for the true timeout time. (Instead of the other fake times :)
 [2005-11-08 09:50 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2005-11-08 17:31 UTC] seth at pricepages dot org
Please excuse any of my ignorance, I haven't worked at the socket level before. (Well, only once, and that was for a Comp. Sci. class.) I think the problem that I am having with the listener is that I don't see how the listener can respond to an expired timeout. It can check the elapsed time, but it can't do anything about it without changing the interface between the Response and the Listener classes. Also, no ticks are called during the reading of the header (from what I can tell from the code). I suppose I could add a "shouldEndRequest()" method to the Listener class that returns a boolean, but you run into problems with multiple listeners, or calling Request::getResponseBody after a listener ends the request. It just seems like it opens up a big can of unpredictable behavior. Also, how would the Listener deal with setting the socket's timeout so the various Socket::readLine calls would return at an appropriate time? Instead of shouldEndRequest, we could use timeRemaining, and for each readLine call, set the socket timeout to be the time returned from timeRemaining. The best way that I see it working is if the code is located in the request and response classes. However, if you prefer shouldEndRequest or timeRemaining, I'd be willing to work on it.
 [2006-10-11 11:01 UTC] lobbin at gmail dot com (Robin Ericsson)
This is related to a problem with readTimeout I'm having. As far as I've debugged this. HTTP_Request sets this on Net_Socket which uses stream_set_timeout , but something probably in Net_Socket or PHP makes the timeout not work, however, it works with the really small example available on stream_set_timeout manual page.
 [2008-10-17 21:12 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2009-01-04 11:24 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!