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] http://pear.php.net/package/HTTP_Request2/

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.

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.

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.

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.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net 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.