It’s a well know fact that you can preform HTTP requests with CURL. Zend Framework does the same job with Zend_Http. Especially Zend_Http_Client can be used to “replace” the usual client – the browser, and to perform some basic requests.

I’ve seen mostly GET requests, although Zend_Http_Client can perform various requests such as POST as well.

// new HTTP request to some HTTP address
$httpClient = new Zend_Http_Client('http://www.example.com/');
// GET the response
$response = $httpClient->request(Zend_Http_Client::GET);

Here’s a little snippet showing how to POST some data to a server.

// new HTTP request to some HTTP address
$client = new Zend_Http_Client('http://www.example.com/');
// set some parameters
$client->setParameterPost('name', 'value');
// POST request
$response = $client->request(Zend_Http_Client::POST);

Note that the request method returns a response. Thus if you are simulating a form submit action you can “redirect” to the desired page just like the form.

// new HTTP request to some HTTP address
$client = new Zend_Http_Client('http://www.example.com/');
// set some parameters
$client->setParameterPost('name', 'value');
// POST request
$response = $client->request(Zend_Http_Client::POST);
echo $response->location;

What is typical for most of the web servers is that they listen for requests and respond as quickly as possible on every one of them. In fact the speed of the response is one of the main targets of optimization for developers. Fast servers are what everyone needs. From web developers to website visitors!

In the field of the that battle different web servers have different “weapons” to gain time. While this is useful in most of the cases, when it comes to a chat-like applications and Node.js approaches, the response is not always immediately returned. As I described in my posts until now about Node.js, a simple web server may wait for an event to be emitted, and than return the response.

I wrote about how to write the very first server, but than I didn’t described how to make a “non-responding” server. By the term “non-responding” I mean a server that responds not immediately after it has received and parsed/executed the request.

A typical web server, responding immediately on every request, written with Node, this may look like so:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

The code that shows us that the request is executed and responds in these lines:

  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');

Actually by commenting/removing those lines you’ll get a server that simply doesn’t respond – ever! This of course is not the main goal, but you can start from somewhere.

var http = require('http');
http.createServer(function (req, res) {
  // res.writeHead(200, {'Content-Type': 'text/plain'});
  // res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

This is how you can hold for a while. Perhaps putting these lines in a conditional statement and periodically checking for some event to occur will do the job.

var http = require('http');
http.createServer(function (req, res) {
  if (something) {
     res.writeHead(200, {'Content-Type': 'text/plain'});
     res.end('Hello World\n');
  }
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

Looping Server

As described in the code above if you put the respond into a conditional you can possibly return the response after some event has fired. The only thing is to periodically loop and check for this condition to be true. Assuming your server’s code is in server.js, started with the “node server.js” command, you’ve to put this code into it:

var http = require("http"),
    fs	 = require("fs");  

// we create a server with automatically binding
// to a server request listener
http.createServer(function(request, response) {
	checkFile(request, response);
}).listen(8124);

function checkFile(request, response)
{
	var date = new Date();
	if (date-request.socket._idleStart.getTime() > 59999) {
		response.writeHead(200, {
			'Content-Type'   : 'text/plain',
			'Access-Control-Allow-Origin' : '*'
		});

		// return response
		response.write('OK', 'utf8');
		response.end();
	}

	// we check the information from the file, especially
	// to know when it was changed for the last time
	fs.stat('filepath', function(err, stats) {
		// if the file is changed
		if (stats.mtime.getTime() > request.socket._idleStart.getTime()) {
			// read it
			fs.readFile('filepath', 'utf8', function(err, data) {
				// return the contents
				response.writeHead(200, {
					'Content-Type'   : 'text/plain',
					'Access-Control-Allow-Origin' : '*'
				});

				// return response
				response.write(data, 'utf8');
				response.end();

				// return
				return false;
			});
		}
	});	

	setTimeout(function() { checkFile(request, response) }, 10000);
};

Note: you must change “filepath” with an existing file path in your system.

Here we can read periodically the file’s mtime, which is the modify time. Thus whenever the file is changed the server will return the response. It’s interesting to note that if no change occurs within the timeout period you’ve to return some status message as we did in those lines:

        
var date = new Date();
if (date-request.socket._idleStart.getTime() > 59999) {
	response.writeHead(200, {
		'Content-Type'   : 'text/plain',
		'Access-Control-Allow-Origin' : '*'
	});
	
	// return response
	response.write('OK', 'utf8');
	response.end();
}

The client side should long poll this server. The example bellow is written in jQuery. The only “special” thing is that after receiving the response, you must call the server again.

The Client

The client is nothing new to the jQuery/JavaScript community except you must call again the server when the response is returned:

function callNode() {
    $.ajax({
        cache : false,
		// setup the server address
        url : 'http://www.example.com:8124/',
        data : {},
        success : function(response, code, xhr) {

            if ('OK' == response) {
            	callNode();
                return false;
            }

            // do whatever you want with the response
            ...

            // make new call
            callNode();
        }
    });
};
callNode();

Summary

As Node can hold the response, the only thing you should do is to check periodically for something as in this example this was a file change. Than it’s important to change the client so it can call the server after the response from it is received.

Typically Node can be used for chat-like applications or whatever apps that must deliver real time data, but for sure it is really great software.

After Node.js is istalled, described in my previous post, I can simply run this command:

stoimenpopov:~# node server.js

and this will start the server with the code within server.js. But what’s the code of server.js?

Following the instructions of Node’s homepage and most of the tutorials I’ve found, I can simply copy/paste the code from the first lines of Node’s page:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

There are several things I find interesting in this code, making it different from JavaScript as we know it. First of all what is

var http = require(‘http’)

and why I need it? What is the purpouse of 8124 and 127.0.0.1?

Node is built in modules and to use one of them you must first include it with require. Just like the example above with require(‘http’). In the same manner you can include every module of Node.

What are the Node’s modules are pretty well described in the API page. Well I’d like to say that the API page is quite insufficient. That is very bad, cause most of the code you’ll need developing a node.js applicatoin isn’t described/explained there.

However is more than obvious that 8124 is the port, while 127.0.0.1 is the IP address of the server, which in this case is the localhost. Thus after running the server and typing http://127.0.0.1:8124/ into your browser you’ll get “Hello World”. This is not enough when the server is running on a remote machine, while you’ve to access it from your local computer.

The first server

As I described the code above shows you an example server. In fact the API page shows a slightly different code:

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello World\n');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

Here the line:

}).listen(8124);

omits the address of the server. It appears to be non-required and the server is supposed to listen on this machine on the given port. To be honest I’m not sure why you’ve to write the server address, except for limit the possible address to this one. However in my case the server was installed on a remote machine indeed, while I was trying to access it from my local machine. So here are some base steps to do before accomplishing this.

1. Changing the IP address

First of all you can omit the IP address. This can help you move the code from one server to another without changing the code.

}).listen(8124, ip_address);

possibly a better solution is:

}).listen(8124);

Node can listen on whatever port you say so this is up to you to decide which port should be opened.

2. Opening the port

While everything’s on the localhost you wont have problems with port opening. If you’d like to access it remotely however, you’ve to open the port. In other words http://127.0.0.1:8124/ is OK without port opening, but http://example.com:8124/ – is not!

To open a port in UNIX/Linux you’ve to type this command in the terminal:

iptables -A INPUT -p tcp --dport 8124 -j ACCEPT

don’t forget to change the port number from 8124 to whatever port number you’re using.

3. The first AJAX call

We still cannot make the first AJAX call to the Node server. Here I’m using jQuery because of the easy AJAX interface.

$(document).ready(function() {
	$.ajax({
    	// setup the server address
        url : 'http://example:8124/',
        success : function(response) {
        	// on success
        	alert(response);
		},
        error : function() {
        	// on error
        }
    });
});

After executing this code in a browser there wont be a response. That is because of the remote AJAX calls restriction. To overcome this you’ve to change the returned header from the Node’s server, by adding this:

'Access-Control-Allow-Origin' : '*'

Now server.js will look like this:

var http = require('http');

http.createServer(function (request, response) {
	response.writeHead(200, {
		'Content-Type': 'text/plain',
		'Access-Control-Allow-Origin' : '*'
	});
	response.end('Hello World\n');
}).listen(8124);

you can now either load http://example.com:8124/ into your browser or to make the AJAX call. In both cases the answer will be “Hello World”

Summary

Now you have a very simple Node.js server. Well it is nothing special as it responses with “Hello World” on every request, but it works remotely.

Soon I’ll describe how to change the server so it can waits to respond until some event is emitted – which is the real power of Node.js.

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.