[wp-hackers] Pinging Support for HTTP Request API

[Jacob]

This is in reference to ticket #4779 [2], made some time ago for those 
that have hosts that disable fsockopen and need other ways to GET/POST 
urls in the core. I'm nearing completion of the API and request feedback 
on the now working API.

Unit tests show that the new HTTP Request API works and allows for basic 
SSL transport. This allows for the complete conversion of the core code 
over to the API (no patch for that yet). Building the API was easy, 
polishing it and fixing bugs is what is taking the most time. While 
writing the unit tests is also taking some time, it is part of the 
polish stage and has been extremely helpful in correcting problems in 
the code.

I'm planning on submitting a patch that converts all of the WordPress 
code (admin, importing, includes) that uses fsockopen, curl, and fopen, 
as well as Snoopy over to the new system.

I submitted the unit test code and most recent HTTP API code to get 
feedback on whether it is supported and has any chance of getting into 
the core. If committed, it would fix Tickets #5065 [1] and #4779 [2]. It 
would also provide a way to install plugins that would provide fall 
backs when allow_url_fopen is disabled and fsockopen function is 
disabled. If cURL is installed then a plugin could use that to get and 
post to URLs.

The only tested transport is fsockopen, which should provide support for 
most people, the rest of the four have fallen behind in improvement to 
the fsockopen method and would need to be tested and fixed. cURL 
extension support is not finished and will not be completed until the 
rest are.

Examples for invoking the API:

<?php $body = wp_remote_get_body('http://www.wordpress.org'); ?>

This will automatically be redirected to 'http://wordpress.org' and then 
return the body (fsockopen only, fopen should do this, but untested).

<?php $arrResponse = wp_remote_get('http://www.wordpress.org'); ?>

$arrResponse['body'] gives you the body. $arrResponse['head'] gives you 
the headers in array form.

There are also wp_remote_get_head() which returns an array of the 
headers and wp_remote_get_object(), which retuns the object used to get 
the request. The latter method allows you access to more data, such as 
response information and raw error information (the other methods will 
return WP_Error object).

*Unit Tests:* The unit tests were written for the automattic unit test 
suite, but since no mocks are used for the remote calls, the tests can 
take quite a while to complete, since the results are "live." I had to 
choose this method, because I was more concerned with the live test data 
and how well the API would work, then using mocks which wouldn't give a 
good indication of whether it worked or not.

 From the unit tests, I can say that the FSockopen method works great 
and the API is ready for testing. I'm going to complete the other four 
classes and wrap them in a plugin. The other four will be in a plugin 
and just the fsockopen one will be in the core (if accepted).

So the questions I propose are:

1. Are there any parts anyone is not okay with?
2. For the core devs: does this still stand a chance of being included 
in the core? If not, then what design goals need to be met before it can 
be included?
3. If this was included in the core, would any plugin authors use it 
instead of using fsockopen? Since the API is GPL, it would be completely 
possible for the plugin authors to include it if it doesn't exist.

Any others for me?

[1] http://trac.wordpress.org/ticket/5065
[2] http://trac.wordpress.org/ticket/4779



-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.