Relative encoding is another data compression algorithm. While run-length encoding, bitmap encoding and diagram and pattern substitution were trying to reduce repeating data, with relative encoding the goal is a bit different. Indeed run-length encoding was searching for long runs of repeating elements, while pattern substitution and bitmap encoding were trying to “map” where the repetitions happen to occur.

The only problem with these algorithms is that not always the input stream of data is constructed out of repeating elements. It is clear that if the input stream contains many repeating elements there must be some way of reducing them. However that doesn’t mean that we cannot compress data if there are no repetitions. It all depends on the data. Let’s say we have the following stream to compress.

1, 2, 3, 4, 5, 6, 7

We can hardly imagine how this stream of data can be compressed. The same problem may occur when trying to compress the alphabet. Indeed the alphabet letters the very base of the words so it is the minimal part for word construction and it’s hard to compress them.

Fortunately this isn’t true always. An algorithm that tryies to deal with non repeating data is relative encoding. Let’s see the following input stream – years from a given decade (the 90’s).

1991,1991,1999,1998,1991,1993,1992,1992

Here we have 39 characters and we can reduce them. A natural approach is to remove the leading “19” as we humans often do.

91,91,99,98,91,93,92,92

Now we have a shorter string, but we can go even further with keeping only the first year. All other years will as relative to this year.

91,0,8,7,0,2,1,1

Now the volume of transferred data is reduced a lot (from 39 to 16 – more than 50%). However there are some questions we need to answer first, because the stream wont be always formatted in such pretty way. How about the next character stream?

91,94,95,95,98,100,101,102,105,110

We see that the value 100 is somehow in the middle of the interval and it is handy to use it as a base value for the relative encoding. Thus the stream above will become:

-9,-6,-5,-5,-2,100,1,2,5,10

The problem is that we can’t decide which value will be the base value so easily. What if the data was dispersed in a different way.

96,97,98,99,100,101,102,103,999,1000,1001,1002

Now the value of “100” isn’t useful, because compressing the stream will get something like this:

-4,-3,-2,-1,100,1,2,3,899,900,901,902

To group the relative values around “some” base values will be far more handy.

(-4,-3,-2,-1,100,1,2,3)(-1,1000,1,2)

However to decide which value will be the base value isn’t that easy. Also the encoding format is not so trivial. In the other hand this type of encoding can be useful in som specific cases as we can see bellow.

Implementation

The implementation of this algorithm depends on the specific task and the format of the data stream. Assuming that we’ve to transfer the stream of years in JSON from a web server to a browser, here’s a short PHP snippet.

// JSON: [1991,1991,1999,1998,1999,1998,1995,1997,1994,1993]
$years = array(1991,1991,1999,1998,1999,1998,1995,1997,1994,1993);

function relative_encoding($input)
{
	$output = array();
	$inputLength = count($input);
	
	$base = $input[0];
	
	$output[] = $base;
	
	for ($i = 1; $i < $inputLength; $i++) {
		$output[] = $input[$i] - $base;
	}
	
	return $output;
}

// JSON: [1991,0,8,7,8,7,4,6,3,2]
echo json_encode(relative_encoding($years));

Application

This algorithm may be very useful in many cases, but here’s one of them. There are plenty of map applications around the web. Some products as Google Maps, Yahoo! Maps, Bing Maps are quite famous, while there are very useful open source projects as OpenStreetMap. The web sites using these apps are thousands.

A typical use case is to transfer lots of Geo coordinates from web server to a browser using JSON. Indeed any GEO point on Earth is relative to the point (0,0), which is located near the west coast of Africa, however on large zoom levels, when there are tons of markers we can transfer the information with relative encoding.

For instance the following diagram shows San Francisco with some markers on it. Their coordinates are be relative to the point (0,0) on Earth.

Far more useful may be to encode those markers, relative to the center of the city, thus we can save some space.

However this type of compression can be tricky, for example when dragging the map and updating the marker array. In the other hand we must group markers if we have to load more than one city. That’s why we must be careful when implementing it. But in the other hand it can be very useful - for instance on initial load of the map we can reduce data and speed up the load time.

The thing is that with relative encoding we can save only changes to base value (data) - something like version control systems and thus reducing data transfer and load. Here's a graphical example. In the first case on the diagram bellow we can see that each item is stored on its own. It doesn't depend on the adjacent items and it can be completely independent of them.

However we can keep full info only for the first item and any other item will be relative to it, like on the diagram bellow.

No matter how fast today’s computers and networks are, the users will constantly need faster and faster services. To reduce the volume of the transferred data we usually use some sort of compression. That is why this computer sciences area will be always interesting to research and develop.

There are many data compression algorithms, some of them lossless, others lossy, but their main goal aways will be to spare storage space and traffic. These algorithms are very useful when talking about data transfer between two distant places. Perhaps the best example is the transfer between a web server and a browser.

In the last few years a lot of research has been done on compressing files, executed on the client side. Such files are javascript, css, htmls and images. In fact servers and clients already have some techniques to compress data, like using GZIP for instance, that can dramatically decrease the transfer. In the other hand there are lots of tools and tricks in order to decrease the size of the data.

Actually when a file is executed by the client’s virtual machine, it doesn’t matter how “beautifully” it is formatted from a programmer’s point of view. Thus the spaces, tabs and the new lines don’t bring any significant information for the environment. That is why such compressing tools like YUI Compressor, Google Closure Compiler, etc. remove those symbols. Well, they can achieve even more in order to improve the compression rate. In this post I won’t cover this, but this shows how important data compression algorithms are.

It would be great if we could just compress data with some tool. Unfortunately this is not the case and usually the compression rate depends on the data itself. It is obvious that the choice of data compression algorithm depends mainly on the data and first of all we must explore the data.

Here I’ll cover one very simple lossless data compression algorithm called “run-length encoding” that can be very useful in some cases.

Overview

This algorithm consists of replacing large sequences of repeating data with only one item of this data followed by a counter showing how many times this item is repeated. To become clearer let’s see a string example.

aaaaaaaaaabbbaxxxxyyyzyx

This string’s length is 24 and as we can see there are lots of repetitions. Using the run-length algorithm, we replace any run with shorter string followed by a counter.

a10b3a1x4y3z1y1x1

The length of this string is 17, which is approximately 70% of the initial length. Obviously this is not the optimal way to compress the given string. For instance we don’t need to use the digit “1” when the character is repeated only once. In some cases this approach can increase the length of the initial string which is exactly the opposite of what we need. In this case we’ll get the string bellow.

a10b3ax4y3zyx

Now the length of the resulting string is 13, which is 54% of the initial length! A variation of the example above is not to keep a counter of the repetitions of the character, but their position instead. Thus the initial string will be compressed as follows.

a0b10a13x14y18z21y22x23

Which of these two approaches you’ll use depends on the goal. In the second case we can achieve a good optimization of binary search.

It is clear that this algorithm is not only applicable on strings. We can achieve very good results on arrays. A typical example is the transfer of JSON from a server to a client. Then if there are large sequences of repeating data we can achieve great results.

Implementation

The implementation bellow is assuming that we’re compressing a string and it’s written on PHP. However the nature of this algorithm doesn’t restrict us to use only strings. As I said before with slight modifications we can use it with other data structures. It is important only to understand that the run-length algorithm is very useful on large sequences of repeating elements, no matter characters or array items.

$message = 'aaaaaaaaaabbbaxxxxyyyzyx';

function run_length_encode($msg)
{
	$i = $j = 0;
	$prev = '';
	$output = '';
	
	while ($msg[$i]) {
		if ($msg[$i] != $prev) {
			
			if ($i) 
				$output .= $j;
				
			$output .= $msg[$i];
				
			$prev = $msg[$i];
			
			$j = 0;
		}
		$j++;
		$i++;
	}
	
	$output .= $j;
	
	return $output;
}

// a10b3a1x4y3z1y1x1
echo run_length_encode($message);

And slightly optimized.

$message = 'aaaaaaaaaabbbaxxxxyyyzyx';

function run_length_encode($msg)
{
	$i = $j = 0;
	$prev = '';
	$output = '';
	
	while ($msg[$i]) {
		if ($msg[$i] != $prev) {
			
			if ($i && $j > 1) 
				$output .= $j;
				
			$output .= $msg[$i];
				
			$prev = $msg[$i];
			
			$j = 0;
		}
		$j++;
		$i++;
	}
	
	if ($j > 1)
		$output .= $j;
	
	return $output;
}

// a10b3ax4y3zyx
echo run_length_encode($message);

Finally a small change – now we store the position of the character.

$message = 'aaaaaaaaaabbbaxxxxyyyzyx';

function run_length_encode($msg)
{
	$i = 0;
	$prev = '';
	$output = '';
	
	while ($msg[$i]) {
		if ($msg[$i] != $prev) {
				
			$output .= $msg[$i] . $i;
				
			$prev = $msg[$i];
			
		}

		$i++;
	}
	
	return $output;
}

// a0b10a13x14y18z21y22x23
echo run_length_encode($message);

Complexity and Data Compression

We’re used to talk about complexity of an algorithm measuring time and we usually try to find the fastest implementation, like in search algorithms. Here it is not so important to compress data quickly, but to compress as much as possible so the output is as small as possible without lossing data. A great feature of run-length encoding is that this algorithm is easy to implement.

Application

We can use run-length encoding in many cases. It is commonly used to compress images and is very successful when we deal only with black and white images. Here I’ll cover another use case that I only mentioned above. Let’s say we have to transfer a very large array of data to our AJAX-powered application using JSON. Let’s say also that the data are some years, for instance the years of the premiere of a movie. There are lots of movies with a premiere in the same year, thus although the data is sorted, we actually can’t have any benefit. More important is that we have large sequences of data. Here we can use run-length encoding.

$data = array(
	0 	=> 1991,
	1 	=> 1991,
	...
	2223 	=> 1991,
	2224 	=> 1992,
	...
	19298 	=> 1995,
	19299 	=> 1996,
	...
);

As you can see to transfer the whole array can be a nightmare, especially on slow networks. It is better to compress it (i.e. with PHP’s json_encode).

// {"0":1991,"1":1991, ..., "2223":1991,"2224":1992, ..., "19298":1995,"19299":1996, ...}
echo json_encode($data);

After running run-length encoding we can receive something like the following array (note that these are only sample data and it’s up to you to decide which is the best format to store data).

$data = array(
	0 => array(1991, 2224),
	1 => array(1992, 3948),
	2 => array(1995, 2398),
	3 => array(1996, 3489),
);

And the JSON output.

// [[1991,2224],[1992,3948],[1995,2398],[1996,3489]]
echo json_encode($data);

Note that if the data is sorted we can achieve great success compressing it!!! This approach can be used for images, graphics or map coordinates.

This is only one example of how data compression can be useful in our daily work. Although the communication between the server and the client can be optimized and compressed, we can improve it. In other words we’re not always sure that the opposite side supports compression.

Well, it’s true that the client has to decompress the data, which can also be slow. Now in the first case we have only the time to transfer, as on the diagram bellow.

In the second case, we should sum the time for compression, transfer and decompression.

All this is important, but in general data compression can be handy in many cases in our daily work.

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.

First of all the use of some software is needed not because of itself, but because of the need of some specific functionality. In my case this was the need of real time news feed. Of course there is a way to make this without Node.js, as I’ll describe later in this post, but there are several disadvantages. However to begin from somewhere, let me explain what is Node.js.

Introducing Node.js

Perhaps the best way do describe what is Node.js is from its about page.

Node’s goal is to provide an easy way to build scalable network programs. In the “hello world” web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation.

…

In general Node is a program using the Google Chrome’s V8 JavaScript engine, which in turn is a program that can parse and execute code written in JavaScript. V8 is a very very interesting project itself. First of all from Google have developed this engine especially for one of his products – their browser Chrome. It pretends to be and by no means is one of the masterpieces of Google. It is fast and reliable engine, written in C++ and JavaScript, as Wikipedia’s page says. Actually this code is open source and can be embedded in whatever application written in C++. Thus you can have in your application a JavaScript engine.

Such kind of application/server is Node.js. With V8 embedded into, Node is intended to run on a machine and to serve some requests. Just like a normal web server, but with few differences. First of all Node is not only serving HTTP requests, but also TCP. Well I’m not so deep into this yet, but so far that works for me. What I need for now is its web serving functionality.

The way Node works, however is different from what we know from every other web server. Here it is a normal server in general:

Whenever a request comes to the server, it tries to return the response as fast as possible. This is one of the main goals of every web developer team – to make the application as fast as possible. However in Node the things work different:

Here the server doesn’t return immediately the response, but holds as long as possible until some “event” occurs. You can thing of Node as a classical chat server. Until one of the peers doesn’t write a message, the other doesn’t receive anything.

Some may be confused as how you can use both the typical web server, as Apache, with Node as another web server within the same page. The answer is – with AJAX. As you know thus you can have only one chunk of your page talking with the server – in this case the entire page is returned by Apache, but inside the page you can have a chat app using Node as a server, working perhaps on a different port on the same machine.

Typically this scenario can be simulated without Node, but as I said, with some disadvantages. Let’s say you have two browsers and one server – you can infinitely loop AJAX calls to the server and whenever there is new message on the server return it to the browser – this is quite inefficient. There are two approaches in this case.

1. You can make those AJAX calls too recently and you can have a call every N seconds. In that case if N is to short you’ll have too many calls and in case the other peer doesn’t make anything the server will be unusually loaded with no practical effect.
2. In the second case you can choose to make N too long – for instance 20 seconds. This is also bad, because during this period of time the peers may want to interact and chat.

In that case Node is a web server, but simply doesn’t return the response until a specific event doesn’t occur. How does this look like in a web browser. You may know how looking into the Firebug console for every AJAX call you see the request and how many seconds it has taken. If you make an AJAX call to a Node server app the request just doesn’t respond immediately.

Installing Node.js

The process of installation is described quite well, so I’m going to describe it in few steps.

1. Download the application from Git, note that V8 is embedded inside. The version while this post was written and of course was stable is v0.2.4
2. For those familiar with Unix/Linux systems, there are three simple steps following, however without GCC (Gnu Compiler Collection) you wont be able to proceed! I’m writing this especially for the Mac OS users, as they may know there is no built-in GCC there.
3. ./configure
4. make
5. make install
6. make test (optional)

This in general is enough. After all that you can write the node command in your terminal. However if there are some problems while compiling it you may refer to Git and the Node community for more help. Don’t forget that V8 can work only on x86, x64 and ARM architectures.

Summary

There are few things that can be summarized now:

1. First of all Node can be a web server, as Apache is, but with the option to respond on event firing.
2. You can request it either with a web page loaded in your browser or within a chunk of the page via AJAX.
3. To install Node you need GCC. It comes with V8 JavaScript engine inside, which can run only on x86, x64 and ARM.

So far so good! Now we have Node installed, practically useless, because there is no application running on it. In my next post I’ll describe how to run your first application.

First of all there are several things to know about Zend Framework and caching. Whenever you work on a big web application caching is one of the mostly used mechanisms of speeding up the app and improve user performance. In general the task and the solution are pretty simple and natural.

As the application grows up the visitors become more and more impatient about what they receive. A single page is becoming slower and slower and the result is painful. First of all every time a user hits a page the application server uses the web server, a script interpreter, a database server and potentially the file system. But that’s not all. After all this output is generated on the server, as HTML in the most cases, it is sent to the client where again CSS and JavaScript engines parse and execute them.

In this scenario it’s easy to imagine how many time is spent. While there are several techniques to optimize the client side by optimizing JavaScript, CSS and the static images used for the design of the site, here I’m going to talk more about the backend.

Beside the Optimization

Let’s assume we’ve one of the very used combination between Apache (as a webserver), PHP (as server scripting language) and MySQL (as database server). Here you can choose to optimize all three of them. However beside the optimization of them one of the most simple steps you can do is to cache the output generated by these three branches of your web app.

Caching the Content

In fact you can cache only single parts of the whole process. For instance you can cache only the result returned by some slow database query. Let’s imagine a query takes about 2 seconds to execute. Now you can cache the result into a file and during the cache is active, i.e. it has not expired, the application takes it from a file stored somewhere in the file system.

In a typical Zend Framework scenario you can first setup the frontend and backend options of the cache.

$frontendOptions = array(
	'lifetime'                => 600, // in seconds - this is 10 seconds
	'automatic_serialization' => true,
);
$backendOptions = array('cache_dir' => 'cache/');
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
		
$cacheKey = md5('mykey');

if (!$cache->load($cacheKey)) {
	$slowQueryResult = $article->fetchAll();
	$cache->save($slowQueryResult, $cacheKey);
} else {
	$slowQueryResult = $cache->load($cacheKey);
}

You can setup different options here by setting up the cache directory, lifetime, etc.

Note that the cache directory must exists and with write permissions and Zend Framework doesn’t create it for you and will throw error.

The problem here is that now you cache only part of the generated content and in many cases this is still too slow for most of the users. However all the work (in most of the cases) of the web server, the script interpreter and the database server result in a simple HTML output. What if you have this output generated or cached for you and when the user hit the page the server will return this pre-generated code?

This is indeed very fast, because it’s similar to return a text file, as the HTML is simply formatted text.

Caching the Entire Page

Before I proceed, I’d like to say that I work with Zend Framework 1.9.x. Now in the latest versions of ZF there are new mechanisms of caching the output even Zend_Cache_Frontend_Page works fine on them.

You can simply setup the page cache within few simple lines of code:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
	'cache' => true,
         'cache_with_cookie_variables' => true,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

However my advise is to place this code as high as possible, because this will cache everything generated as output. It’s a good practice if you place this even in the bootstrap before you make the connection with the database. Actually you don’t need a database connection when you’ve to return a simple text(html) file.

This will improve your app’s performance a lot!

However there are few things to know. When you setup the cache to work even with cookie variables, you can see that hitting the page with different browsers Zend Framework will generated different cache pages. This is quite useless because than you don’t have any benefit of caching the content.

First of all let me say that THIS IS NOT A BUG! of ZF. Simply the framework will use the cookie variables to generate the cache key. It’s obvious that different browsers, even more different users, will have different cookie set and the framework will generate different cache keys for them.

Thus you’ve to change the setting to generate the cache key from cookie variable by explicitly set this option to false:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
		 'cache' => true,
         'cache_with_cookie_variables' => true,
         'make_id_with_cookie_variables' => false,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

Note that in this example we cache every single page generated by the framework explained in the regexps. This is not so good especially when the users have the possibility to login and to see customized content for them, so you can be careful what you cache.

A typical problem that this solution solves is when your application uses Google Analytics. As you may know Google Analytics sets up a cookie every time when an user hits the page, so every time the framework will generate a different cache for him and in result he won’t see any benefit and performance improvement from your site.

Zend_Form and Zend_Form_Element_Hash

Although the technique I’m using is doing the same thing, note that in ZF there’s a Zend_Form_Element_Hash which generates and validates the form, thus protecting you from CSRF attacks. The thing is that I didn’t use it because the form I’m protecting is not generated with Zend_Form, and I cannot benefit from everything ZF is giving to me. However you can easily reproduce the basic strategy with every form and every framework till it’s written in PHP.

What’s the solution?

It’s pretty simple and it’s described many many times around the web, simply generate a random hash, a possible solution is to use uniqid in combination with mt_rand and md5, thus you’d get quite strong hash.

Step two is to pass this generated hash, also stored in the session in a hidden value of the form. Of course now the most asked question is: but that’s visible to the source and thus everybody will have a valid hash.

There’s the trick. OK everybody will have a valid hash, but on submit the hash is validated against the SESSION variable, and as you know the session is specified between the browser (client) and the web server. Although the attacker may have a valid hash he must execute the attacking script from the same domain, possibly with the same browser, which makes the task rather difficult.

An Example

Let me show a breve example, it may help make things clearer.

1. First step – start the session

<?php
session_start();
?>

2. Second step – validate the form against the $_SESSION and generate a valid token

<?php
if (isset($_POST['name']) && $_POST['token'] == $_SESSION['token'])
    echo $_POST['name'];
else
    echo 'dont hack';

$_SESSION['token'] = md5(uniqid('test', true));
?>

3. Third step – make a form

<form method="POST" action="">
<input type="hidden" value="<?php echo $_SESSION['token'] ?>" name="token" />
<input type="text" name="name" value="stoimen" />
<input type="submit" name="submit" />
</form>

Demo here.

For more to test this you may try to make the same form somewhere else on the web and to point the action to http://www.stoimen.com/projects/php.secure.forms/! Without the session validation it’s absolutely sure you can post on the attacked server.

P.S. Now I’ve to admit that this have nothing to do with Zend Framework, however it’s good practice and thus may be used with every framework.

In fact how and why should I optimize CSS is the right question. Actually CSS is simply one ore more files loaded from the server to the client, usually a browser, with CSS specific rules that must be applied by the browser to the web page you’re seeing. That’s in general. Of course there are exceptions when CSS can be inline or added directly to the HTML tags, which is bad practice because thus the HTML markup becomes larger and even worse the browser cannot cache it and than load it quickly. In fact that’s why usually the CSS of a web page is put in one single file. Primary because that makes only one request to the server and in second hand because it can be cached by the browser.

Just because the nature of the CSS is that firstly it’s loaded and than executed one of the primary techniques of optimizing it is to make it smaller and therefore load faster. There are several methods of doing so. Enabling GZIP support of the web server and minifying the file are the most common ones. But one of the tricks you cannot optimizing just for second is using the so called CSS sprites.

CSS sprites

What are these? To answer this question I’ll simply try to give you an example. Let’s assume there are three CSS classes each one with its own background image. This makes four requests to the server. One for the CSS file and one per every background image. But what we’d like to achieve is to make less requests as we can. Than one of the things we can do is to make one single image and to change only the background-position CSS property to position it on the right place and to make it appear correctly.

Be careful! When you join all of the images into one single CSS sprite you may add one class with that background-image and every other class with only background-position property. Than every DOM element with that background must have both class names. Only than you can be sure the server will make two requests. One for the CSS file and one for the sprite.

base64 to encode images

In other hand most of the web projects are pretty big, and unfortunately it’s too difficult to make only one single sprite just because it’s too difficult to manage it after the project has become very large. That’s why mostly in the practice there are several sprites for the main components. But the problem is that again there are more HTTP requests.

Is there any way to make only one request?

Yes there is. Simply by converting your CSS sprite into a base64 encoded image. In breve base64 is an encoding where you can practically make any data into a string. Thus the image can be represented by a string containing the same information as the image. Hopefully most of the browser, except of course MSIE, does read the so called data urls, or:

<img src="data:image/png;base64,..... " />

and that’s enough to get started with base64 and the single request. The sprite has become a string!

CSS and base64

The natural question is now how to merge all this? You now have one CSS file with one or more sprites. Than you can convert them into a base64 encoded strings and put them all into the CSS.

There is a problem, of course, what happens with MSIE. As I said before MSIE doesn’t read base64 encoded images. Hopefully there is a solution described very well by Stoyan Stefanov in his blog post here.

Finally …

now there is only one request and everything works pretty fine. This technique can be really helpful to someone who’s trying to optimize the CSS performance to the limits.

Why?

Maybe because nobody things that the HTML source of a page can be optimized or the optimization of it cannot bring some benefit to the page load experience. I don’t thing so. If something can be optimized, even if this does not give you so much, why you shouldn’t do it?

How to optimize such thing as HTML?

Well there are few things you should do and other that can speed up a little bit but you should not.

1. Enable gzip

What is gzip? Well in breve everything the server generates is sent back to the client in text format. You’ve to possibilities to send it. Either compressed or uncompressed. As you may guess the compressed format is a lot faster than uncompressed. In fact to make it work that way you’d need to enable gzip which is supported by the web server. In the case of Apache web server this can be done by enabling mod_deflate. Take a look of mod_deflated and mod_inflate. This two modules gives you the possibility to make your site a lot faster and the good news is that this is done without a single line change. The bad news, as always there’s a bad news, is that sometimes this cannot help a visitor, simply because his browser doesn’t support such corresponding with the server. According to a research I’ve read recently almost 15% of the web browsers doesn’t support gzip. Sometimes the reason is old browser versions, sometimes because the state policy doesn’t allow it. However this is the first thing you should do to speed up your HTML even it is not related directly to HTML scripts. By the way this will speed up everything which is sent back to the client, especially CSS and JavaScript files and in the case of JavaScript this can improve dramatically the user experience.

2. Use div elements instead of tables when possible.

This is the second thing you can do to speed up your site. The simple reason to do that is because the DIV element doesn’t need so much markup as a TABLE element. When widely used in a page – imaging thousands of tables this can be a disaster. Remember the first thing is to make the text you send to the server as small as possible. In that point I should say that not only the tables to div switch is enough. Always prefer smaller tags and constructions. This is a bit difficult. Some experienced web developers can construct the same page with less HTML markup than newbies, but that depends of your level of experience.

3. Make it ugly – just to spend some space.

Your code is beautifully organized and when viewing the source everyone is excited! That was a mistake I used to make in my early projects. Why we thing somebody will take a look of the source code? Why we thing somebody’s using view-source option? Because we’re sick minded web developers. Nobody cares about your well organized source code. Normal users don’t look at it! Forget about beauty! As you may remember – you should spend all the extra spaces you send to the browser. Well if well organized the source code is full of tabulations, new lines and spaces. This is not good! Well if gzip is enabled they may be spent to the client, but if not? Stop writing beautiful HTML. The first task is to make it readable and maintainable.

4. Don’t use inline styling

This cannot be cached by the browser, is difficult to maintain and is – ugly! Yeah don’t use inline styles it makes your markup larger, which yet again is bad and is difficult to maintain. Write everything in CSS files, include them from the outside and setup only the classes you need.

5. Make it maintainable

Although its important to make the HTML as small as possible, sometimes that means to make it as ugly as possible and that brings the enemy number one – unmaintainable code. After a while the change of that code is technically impossible. So use all these techniques with something in mind – make it maintainable even if that will sacrifice some optimization benefits.

Yes in our case this was the fact. There were two web servers, Apache 2 in our case, and one PHP. The php.ini file was in /etc/ as usual. Everything seemed to be perfect. But however some directives in php.ini does not worked for one of the server.

Why the second server does not read php.ini?

Well actually when you load the php.ini for the first server it loads correctly with everthing declared in it. However when you start the second server, of course on a different port than the first one, you get all the php.ini values as if they are default.

Why?

That’s some feature of PHP we didn’t know. I still don’t have an explanation about it. But of cource there’s a …

Workaround

You can put everything for the second server in the .htaccess file, so this will act as second php.ini for the second web server