[wp-hackers] WP HTTP Client

[Eric Marden]

Is the new http.php built on Curl as well?

This is where I was more worried about snoopy than looking for the new  
functionality. I've used snoopy in the past, but was kind of looking  
for something without a dependancy on curl, a'la Zend_Http, but using  
that would add lots of undue files to the plugin, and force it to be  
php5 only.

I'll use snoopy for now, and track the progress of http.php.

Thanks All!

-e



On Sep 7, 2008, at 11:56 AM, Stephane Daury wrote:

>
> On Sep 06, 2008, at 22:28, Jacob Santos wrote:
>
>> Ryan McCue wrote:
>>> Eric Marden wrote:
>>>
>>>> I think I remember seeing a post come across the list about the  
>>>> 'best'
>>>> way to make HTTP calls (get/post) inside of a wordpress plugin, and
>>>> that some said there was a class or set of functions for that.  
>>>> Are we
>>>> talking about wp-includes/class-snoopy.php or is there a better  
>>>> way?
>>>
>>> Jacob Santos' work on it is wp-includes/http.php in trunk (and  
>>> slated
>>> for 2.7).
>>>
>>> Thanks,
>>> Ryan M.
>
>
> But in the meantime, Snoopy does work great if you want/need  
> backward compatibility and portability.
>
> We use it extensively in our plugins, to connect to our remote API.
>
> To be noted though, it only supports get and post, not put or  
> delete, and uses the curl binary (not lib) when under https.
>
> Stephane
>
>
>
>
>
>>>
>>
>> Eric,
>>
>> I had hoped to create something that would totally own Snoopy, but  
>> whatever, the http.php file includes three functions for making  
>> HTTP requests. All of them handle redirection 301, all of them also  
>> handle HTTP 1.1 content chunk encoding (some hosts insist on  
>> sending chunk encoding when HTTP 1.0 requests are made, the  
>> bastards!).
>>
>> I plan on writing a codex page on how to use the functions but  
>> basically, you
>>
>> wp_remote_request("http://www.wordpress.org"); <--- This is used to  
>> test for redirection, if you get nothing, then redirection failed!
>>
>> There are additional arguments you can set for the second  
>> parameter. I think I'll save that for the codex page.
>>
>> wp_remote_get("http://wordpress.org"); <---- This sends the request  
>> as a GET.
>> wp_remote_post("http://wordpress.org", array( 'body' =>  
>> array('something' => 'else') )); <--- This sends the request as a  
>> POST.
>>
>> Yeah, if you send the body as an array, it will be automatically  
>> url encoded and the correct header set.
>>
>> It does a lot for you to make it extremely easy and standard  
>> throughout the transports used. This also means that there will be  
>> bugs and I strongly encourage people to test the HTTP API as much  
>> as possible. There might be a bug in one transport that isn't in  
>> the other transports. The good news is that most of the transports  
>> have been battle tested for about two weeks, so the majority of  
>> people shouldn't have problems, the bad news is that if you have  
>> problems you'll probably be SOL.
>>
>> When I say you, I don't mean you, I mean the person who experiences  
>> problems when 2.7 is released. However, the probably of that  
>> happening goes down with the more people using it and the longer  
>> people use it the more stable it will be. With five transports, it  
>> gets pretty tricky from this point. I would suggest installing the  
>> pecl HTTP extension, if you don't already have it, it appears to be  
>> the most stable.
>>
>> Jacob Santos
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers