Its PEAR's turn to kick my PUT (BUTT) :)

We had a peculiar requirement, in which all the API requests should be sent using PUT method. I never heard of this 'PUT' HTTP method before.

By the way here is my development environment details:

OS : WINDOWS
Framework : Code Igniter (PHP)
DB: MySQL

After vigorous goggling, we found that JQUERY (AJAX) can send HTTP requests by PUT method. Here is the sample link.
Cross-domain issue: There came the 'Cross-domain' issue in Mozilla Firefox when I tried to send HTTP requests to our API. IE 6 will not have this problem. But fixing this cross-domain issue in Mozilla Firefox 3.0 is not as simple as in Firefox 2.x. Changing configuration in pref.js file didn't helped me.

I realized that this not a easy task as i thought.

What about REST? Yaa!! REST can send requests to send HTTP requests in PUT method. We started trying things in a new direction.

Will REST help us????

The fact is even though there are wonderful PHP libraries to send HTTP requests in PUT method, the API provided to us rejected everything. WTF!

Here is the PHP REST servers and clients :
REST PHP class client
REST PHP class server

Again we started our search for the solution. My Tech Lead - Palani gave me the idea of sending the requests in PUT using ROR (Ruby on Rails), this will help us to check whether the API is really accepting PUT method?

I consulted with our ROR team and they gave me a new buzz word 'mechanize' gem.
Here is the code which i used
require "rubygems"
require "mechanize"
require "net/https"
agent = WWW::Mechanize.new
agent.keep_alive = false # true causes TypeError
STDERR #if $DEBUG
agent.put("http://ourapi.com", {"param1" => "0"}, :headers => {"Content-Length" => 50})

Our cute API rejected that too! "What the hell you want me to do?". I shouted.

Again we started our search for the solution. Suddenly I came across PEAR HTTP REQUEST.

HTTP REQUEST is a PHP PEAR package to perform HTTP requests. This package supports all the four HTTP methods to send requests (GET, POST, PUT, DELETE).

This looked promising! I was overjoyed.

At the very next moment, downloaded and integrated it in Code Igniter with the help of this wonderful posting, PEAR integration.

Hurray!! We completed the coding

$this->load->library('Pearloader');
$req3 = $this->pearloader->load('HTTP', 'Request');
$params = 'state=0';
$url = 'http://ourapi.com';
$req3->setURL($url);
$req3->setMethod(HTTP_REQUEST_METHOD_PUT);
$req3->setBody($params);
$req3->sendRequest();
$response3 = $req3->getResponseBody();
echo $response3;
echo '
--------------------------
';

Wait...wait man. We have a twist in the tale. :(

Yes, this code worked charmingly in WINDOWS. But in Linux!!! This thrown the following error..

"Fatal error: Call to undefined method HTTP_Request::setBody() in"

For god's sake, What I did to this LINUX?, I wondered!

Finally, I fixed the issue by changing the line

$req3->setBody($params);

with

$req3->addRawPostData($params);

The funniest thing is, Request.php documentation says, "addRawPostData() is deprecated since 1.3.0, method setBody() should be used instead"

:)

This code worked fine in LINUX also. My problem was solved. Now we can send HTTP Requests in PUT method using PEAR package.

THE END :)

Thanks for reading

DOM PDF sucked me!

DOM PDF is an excellent HTML to PDF converter for PHP. It gives us the flexibility to design our PDF output in HTML format and use that file to generate the required PDF. Looks cool, huh! I never knew the danger behind it when i started using it.

Yes, i have developed my PDF generation requirement using the DOM PDF in my Windows box and the project was about to be delivered. But once i ported it in Linux Box, i was terrified!

In Linux, DOM PDF is not generating the PDF properly. I was clueless. It worked charmingly in Windows. What i observed is that, if the contents (number of pages) exceed more than one page, it doesn't generate the PDF. It was shocked! We (along with my Tech Lead) tried our level best to fix it up. But DOM PDF sucked us. We couldn't arrive at a solution to fix this issue.

At last we gave up DOM PDF and continued our development with FPDF (the savior) and completed the project.

It's a very good lesson for me about the platform specific issues of free codes. I admit that i never posted anything related to this issue in DOM PDF. I have to do it soon.

Thanks for reading this.