Home » HTTP » HTTP_Request » Bug #7691
Timeout values conflict max_execution_time
Details
| Submitted | 2006-05-22 10:51 UTC |
|---|---|
| From | jason dot e dot stewart at gmail dot com |
| Status | Wont fix |
| Package | HTTP_Request |
| PHP Version | 5.0.2 |
| OS | Windows NT |
| Roadmaps | (Not assigned) |
Comments
[2006-05-22 10:51 UTC] jason dot e dot stewart at gmail dot com
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.
[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 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.