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

Request #15072 Use HTTP_Request2 rather than cURL
Submitted: 2008-11-18 18:39 UTC
From: avb Assigned: izi
Status: Closed Package: Services_Twitter (version 0.2.0)
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    

 [2008-11-18 18:39 UTC] avb (Alexey Borzov)
Description: ------------ A new E_STRICT-compatible version of HTTP_Request package [1] has been released, please consider using it instead of relying on cURL extension. If HTTP_Request2 is not yet ready for your package's needs, do not hesitate to open requests for missing features. [1]


 [2008-11-19 12:22 UTC] doconnor (Daniel O'Connor)
Attached is a patch to swap over to HTTP_Request2. It also adds a setter and passes in an object through the constructor - laying the groundwork for Request #15085 if you choose to go that route. Most of the unit tests pass locally; the others appear to be configuration failures - please verify though, Joe! Thoughts: HTTP_Request2 made sense in a lot of places, but: 1) I can't do a HTTP_Request2::setConfigValue($name, $value) - so I had to comment out the 'timeout' option that existed from before. 2) I had a addPostParameter($data); but no addGetParameter($data); - the latter would have been handy in this situation.
 [2008-11-19 13:17 UTC] avb (Alexey Borzov)
Looked at the patch, two points: 1) one can change the value of 'connect_timeout' after instantiating HTTP_Request2 via $this->request->setConfig(array('connect_timeout' => X)); 2) setting GET parameters can be done via $this->request->getUrl()->setQueryVariables($params); of course, setUrl() call should be done before that.
 [2008-12-05 01:02 UTC] gauthierm (Michael Gauthier)
I've reviewed this patch since I'm using HTTP_Request2 in a new package. The way the request object is re-used could cause problems when using addPostParam(). For example, if you make one POST call with one set of parameters and then another call that requires a different set of parameters, the $postParams array will still contain the old request values. You can get around this by keeping a copy of the original request and cloning if before you set properties. This won't work when you pass in a request object to the constructor with bad $postParams though. A removePostParam() and removeUpload() method should be added to HTTP_Request2.
 [2008-12-07 21:41 UTC] avb (Alexey Borzov)
You are right that you should use the original request as a template for cloning. As for passing the request with postParams already set, that's clearly an user error and said user will learn of it quickly enough when a web service refuses to process his data.
 [2009-08-26 18:29 UTC] izi (David Jean Louis)
-Status: Open +Status: Closed -Assigned To: +Assigned To: izi
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.