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

Bug #7691 Timeout values conflict max_execution_time
Submitted: 2006-05-22 10:51 UTC
From: jason dot e dot stewart at gmail dot com Assigned:
Status: Wont fix Package: HTTP_Request (version 1.3.0)
PHP Version: 5.0.2 OS: Windows NT
Roadmaps: (Not assigned)    
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 : 3 + 28 = ?

 
 [2006-05-22 10:51 UTC] jason dot e dot stewart at gmail dot com (Jason Stewart)
Description: ------------ I use a php script to redirect to a network scanner - which scans an image and returns the image URL back to the original script (I would use AJAX, but it's a cross-domain request, boohoo). The problem is that some scans take > 30s, which (after too many hours of debugging) conflicts with the default setting of max_execution_time of 30s. Unfortunately the problem lies in Net_Socket:readLine() which calls @fgets() inside it's while loop. When the error happens no output is generated but the error unwinds all the way back up to my script which called $req->sendRequest() and my script exits prematurely and no amount of error trapping worked. Removing the '@' finally generated the error, and I figured out that I had to bump up max_execution_time. I have no idea why Net_Socket:readline() is calling @fgets() and not fgets() - but it hides critical errors. And it seems that HTTP_Request could detect that the timeout values exceed the max_execution_time and warn users.

Comments

 [2006-05-22 11:02 UTC] jason dot e dot stewart at gmail dot com
this bug is linked to BUG# 7692
 [2006-06-03 10:10 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!
 [2006-06-03 12:38 UTC] jason dot e dot stewart at gmail dot com
what I would like is just a check that compares the timeout values in the Request object to the max_execution_time. If the user thinks he is changing the timeout to a big number - it is a shock when it doesn't work. At least Net::Socket is no longer hiding the error, but HTTP::Request could make it even simpler by issueing a warning that the timeout value is smaller than the max_execution_time. Just a warning would be nice - at least add it to the documentation.... Thanks.
 [2008-04-23 12:33 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!