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

Request #5022 Non-Blocking Requests not support
Submitted: 2005-08-07 19:07 UTC
From: misc at keilonat dot de Assigned:
Status: Open Package: HTTP_Request2
PHP Version: 4.4.0 OS: Windows 2000
Roadmaps: (Not assigned)    
Subscription  
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes. If this is not your bug, you can add a comment by following this link. If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
2008-10-17 21:11 UTC
Package:
Bug Type:
Summary:
From: misc at keilonat dot de
New email:
PHP Version: Package Version: OS:

 

 [2005-08-07 19:07 UTC] misc at keilonat dot de
Description: ------------ Because HTTP_Request::sendRequest() does not only send the request as the name would suggest, but also fetches the data immediately, it is not possible to use this class nor classes based on this (e.g. HTTP_Client) to perform non-blocking (parallel) requests which is very pity. To perform non-blocking requests, one would have to do something like this: <?php $urls = array( 'http://pear.php.net', 'http://php.net', 'http://google.de' ); // only open socket and send request, // no fetching of data or headers! foreach($urls as $url) { $requests[$url] =& new HTTP_Request($url); $requests[$url]->sendRequest(); } // retrieval of data foreach($urls as $url) { $data = $requests[$url]->fetchData(); } ?> If the data is fetched immediately after the request, the effect of socket_set_blocking($fp, 0) is zilch.

Comments

 [2006-05-02 06:30 UTC] justinpatrin (Justin Patrin)
The effect is not zilch. If you set the socket to be non-blocking then a seemingly random amount of data will come back. Sometimes none, sometimes some, sometimes all. In order for this to "work" the response object would need to effectively act like an extension of Net_Socket and allow you to fetch the data as it comes in. Not to mention that the first section of the response, the headers, at least, need to be fetched before *any*thing can be done, such as getting the response code. On top of that the headers are needed in order for HTTP_Request to know if it should redirect and get the redirected URL. Granted, this *could* all be done non-blocking and the second (third, fourth, etc) request could be done on-demand when the body or code is requested, but all of this would take a lerge amount of refactoring and broken API for HTTP_Request. It could likely be done without breaking BC, but this will still take a lot of refactoring. I'm not saying that this can't or shouldn't be done, just trying to lay out what it's going to take.
 [2007-10-24 18:26 UTC] jstump (Joe Stump)
Justin, that's not what he's asking. He's not implying the *socket* should be non-blocking. He's saying that HTTP_Request should send the initial headers and no actually read the data down from the socket until it's requested. It's really common in Services Oriented Architecture to send requests in parallel in this manner asynchronously. I've implemented this in Services_Digg (not yet released, I can get you the code though). Basically you: 1.) Open socket. 2.) Send initial GET/POST headers. 3.) Do nothing until something is requested from that request.
 [2008-10-17 21:11 UTC] avb (Alexey Borzov)
Moving feature requests to HTTP_Request2.