Tag Archives: Hypertext Transfer Protocol

Send Authenticated POST Request with Zend_Http_Client


There is an easy way to send requests with Zend_Http_Client either in GET and POST. Actually you can request not only with GET and POST methods, but with any other http request method.

$httpClient = new Zend_Http_Client('http://....');
// request via post
$response = $httpClient->request(Zend_Http_Client::POST);
// or get
$response = $httpClient->request(Zend_Http_Client::GET);

However the interesting and useful thing is that you can perform authenticated requests:

$httpClient = new Zend_Http_Client('http://username:password@example.com');
// or define it later
$httpClient = new Zend_Http_Client('http://example.com');
$httpClient->setAuth('username', 'password');

That’s an opportunity to send/receive authenticated POST requests.

$httpClient = new Zend_Http_Client('http://username:password@example.com');
// now post
$httpClient->request(Zend_Http_Client::POST);

Zend Examples: GET Parameters Default Value

PHP Style

As you may know in PHP you can access everything in the request uri by accessing the global $_GET array. If there is something like that in the browser’s address field: www.example.com/index.php?controller=index&action=test, you can simply get the values by that:

echo $_GET['controller']; // this will print "index"
echo $_GET['action'];     // this will print "test"

Zend Framework, Uri & Request Params

If you code with Zend Framework, you should know already, and that’s perhaps the first thing you’ve learned about Zend, that $_GET params can be accessed by calling the requrest’s getParam() method. But first of all the request uri will be different. The Zend’s convetion is to place after the domain name first the module name (which is omited when there’s only one module), than the controller’s name followed by the action and the key value pairs of all parameters. In that scheme the request uri above will look like that:

http://www.example.com/index/test

Here the keywords “controller” and “action” are omitted. This is cool – it’s more user friendly and it definitely helps the SEO.

Get the $_GET

Once the uri is setup like so – /index/test you can access it via the Zend way:

echo $this->getRequest()->getParam('controller'); // this will print "index"

The cool thing is that in the first case you don’t have any prevention of a missing value, while in the second case there is a second parameter or the getParam() method that does this job. What if the uri is www.example.com/index.php?controller=&action=test than by printing the $_GET[‘controller’] you’ll get nothing. In other hand even this:

echo $this->getRequest()->getParam('action');

won’t return “test” if the uri is http://www.example.com/index/

Note: actually here the default “index” action will be referenced!

That’s where the power of the framework comes. In the first case the solution is:

echo (empty($_GET['controller']) ? 'default': $_GET['controller']);

while in Zend there’s more elegant solution:

echo $this->getRequest()->getParam('action', 'test');

Thus when the action param is missing the “test” value is considered as default! Very useful!

Check YouTube Video Existence with Zend_Gdata_YouTube

The Video Has Been Removed?!

Have you ever seen the famous message on YouTube: “This video has been removed by the user.”, but what if you’re trying to grab that video via the Zend_Gdata_YouTube?

That can happen when you’re reading the feed for a channel or a user’s list of videos. In the feed everything’s OK – once the video is uploaded it appears into the feed. After that the user removes the video and visiting the link from the feed you’ll get the message above.

Actually what happens when you try to read this “video entry” within a Zend Framework’s application. There must be some way to catch this message?

Trying to Catch

The answer is pretty simple! Zend_Gdata_YouTube’s throwing an exception and it can be easily cached. Here’s some source code:

$apiKey = 'your_api_key';
$client = new Zend_Http_Client();
$gdata = new Zend_Gdata_YouTube($client, 'my-app', null, $apiKey);
try {
       $gdata->getVideoEntry($video_id);
} catch(Zend_Gdata_App_Exception $e) {
       echo $e->getMessage();
}

Zend_Http_Client and Case Sensitivity

Recently I posted about Zend_Http_Client and the ability to check a request HEAD or GET. It is, as everything in Zend Framework, extremely easy to adopt and use, but today I experienced some “strnage” problems!

As I wrote some lines of code,

<?php
....
$client = new Zend_Http_Client('uri_path');
$request = $client->request('head');
...
?>

so far so good, everything worked just perfect until I deployed the “working” code on the production server. Than odd enough some requests just crashed. Not all – just some of them.

Another strange thing was that no exception was thrown.

Maybe using more my intuition instead of my brain I just tried to request the head using capital letter – HEAD. And as everything was strange enough, yet again this solution happened to be working! That solved my problem.

<?php
....
$client = new Zend_Http_Client('uri_path');
$request = $client->request('HEAD');
...
?>

Read Remote File Content-Type with Zend_Http_Client

Check an Image on a Remote Server

This is a common task. You’d like to know whether the image on the remote server exists. Zend Framework gives the answer of this question and in particular this can be completed with Zend_Http_Client.

Content-Type and Content-Length

The little problem is that checking for content-type is not always correct, because it will return an image content type even when the image does not exists, so it’s better to check for content-length.

Code

The simple way to check this is like that:

$client = new Zend_Http_Client('http://remote-machine/image.jpg');
$response = $client->request('head');
if ( NULL == $response->getHeader('Content-Length') )
    // do whatever if the image does not exists.

In fact here, in this example I don’t check for GET request, because is way to slow than the HEAD method, but you should be aware of incorrect responses when using HEAD. In fact if you request the HEAD of a FLV video it will be returned text content-type, while using GET everything’s working fine but slow though.