PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » HTTP » HTTP_Request » Bug #7691

Timeout values conflict max_execution_time

Details

Submitted2006-05-22 10:51 UTC
Fromjason dot e dot stewart at gmail dot com
StatusWont fix
PackageHTTP_Request
PHP Version5.0.2
OSWindows 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.