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.

this bug is linked to BUG# 7692

While there's no problem to add the check for max_execution_time. It won't really solve the problem, though: what happens if you do two requests, each of these will take less than max_execution time but both will run longer? Looks like bug #7692 is now closed, should I close that one as well?

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.

Marking as wontfix, now that Net_Socket no longer supresses errors.