Understood 
However, do you think it’s a good use of your time? You’ve been helping out with a lot of other areas of Yii that have also needed attention (I’ve been watching the pull requests and issues on Github coming through). Would the Yii community be better served if you used the effort you might pore into maintaining / extending this library on other things?
Well, that’s debatable. I’ve already spent quite an amount of time into the first attempt at this and the rewrite is taking up more time than I ever imagined. However, I still feel it is worth the effort. I see myself using this component (quite a way to pat my own back 
) and if others take advantage of it: All the better. And to be honest: atm I’m mostly out of ideas what else I could provide to the core. I’ve got some code cooking that would be good as separate extension, but very little that could or even should find its way into the framework itself.
Hi Da:Sourcerer,
I was wondering… Can you point out some advantages/disadvantages when you compare your chttpclient to ehttpclient?
The main difference I see is that that extension has multiple possible connectors, while you only use streams. Is there any reason for that?
Thanks 
Well, let me start off with saying that most development on CHttpClient is now happening in the new CHttpClient-ng branch. A lot is still happening outside of git for various reasons.
As for your questions: EHttpClient is pretty much a one-shot object. You create it, fire off your http request and need to create a new one if you would want to issue another http request. CHttpClient is different in that regard as it registers as an actual stateless application component, preparing request objects and delegating them to a configured connector. The connectors now are pretty much the same thing as adapters in EHttpClient/Zend_Http_Client or request processors in Habari’s http infrastructure. They are held responsible for pushing the prepared request over the wire and parsing the http response into an according object. The idea of having several connectors is to provide a connector using PHP’s stream sockets, thus being able to work in pretty much every environment, and some others using cURL or pecl::http, providing faster message parsing.
The actual advantages are now a bit abstract. It is definitely easier to set up a set of headers sent among all outgoing requests, as you only need to configure the CHttpClient component accordingly. Caching and cookie management integrate nicer into Yii. I’ve also put some considerable effort into method chaining, so in the end you will be able to do something like this:
echo Yii::app()->http->get('http://example.org')-> //prepare the request
disableCaching()-> //don't send caching http headers
addHeader('DNT','1')-> //send the do-not-track header along
send()-> //send the request out
body //print out the response's body
Oh, and about Guzzle and cURL: I found out that Guzzle indeed uses cURL unconditionally for all network operations. It seems to me the original author wanted to avoid dealing with all the gory details of socket programming. Frankly, I quite understand that. E.g. handling 100/Continue responses with stream_select() is a bit tricky 
I’ve been in a coding-rush during the last days. Only to be stopped by the following unrecoverable error:
If I wouldn’t know better, I’d say PHP just flicked me off 
Getting more and more usable. I just managed to crawl the Wacken Open-Air forum with this code:
$request=Yii::app()->http->get('http://woafor.wacken.com/showthread.php');
for($t=1; $t<=1024; ++$t)
{
$request->url->params['t']=$t;
echo "$t\t";
$response=$request->send();
if($response->isSuccessful())
{
preg_match('/<title>(.+)<\/title>/',$response->body,$matches);
$title=trim(strip_tags($matches[1]));
echo $title.PHP_EOL;
}
else
echo ">> {$response->status} {$response->message}".PHP_EOL;
}
Turns out their forum isn’t very resty and returns 200/Ok for deleted or inexsitant threads