domenica 18 ottobre 2009

How to retrieve data passed inside the request header

Usually the browser provide a lot of information inside the header of a http request: not only the requested page, but also cookies, POST or GET variables, the user-agent etc.etc. All this data are stored in an array of strings and are accessible trough an external variable: environ.

Taking inspiration from the echo.c example of the development kit I made a simple application that gives back all the information stored inside the header and the body of a request, similar to the phpinfo() function present in PHP.

If you want to test the program you can download a zip file here. With the C source there is also a HTML file useful to test different types of GET or POST requests, otherwise you can download the full FLUS environment here where you can test all the example of my blog connecting to the homepage of the server.

Note: under some conditions some data are passed also in the body section of the request.

echo.c example of the Development Kit
URIs, Addressability, and the use of HTTP GET and POSTURIs, Addressability, and the use of HTTP GET and POST
Forms (W3C Reccomendation page)

venerdì 9 ottobre 2009

How to share data between different HTTP requests

An easy way to share data between different HTTP requests of the same FastCGI is declaring variables outside the main loop of the FastCGI. The following FastCGI, a simple web counter, use this technique to maintain into an integer the count of accesses:

#include "fcgi_stdio.h"
int main( int argc, char *argv[] )
int c = 1;
while( FCGI_Accept() >= 0 )
printf( "Content-Type: text/plain\r\n\r\n" );
printf( "%d\n", c );
return 0;

Assuming that the source has been named webcounter.c and application has been compiled (see this post) as webcounter into the /var/fastcgi directory, it’s necessary to add the following lines to the /etc/lighttpd/conf-available/10-fastcgi.conf file:

fastcgi.server += ( "/fastcgi/webcounter" =>;
"bin-path" => "/var/fastcgi/webcounter",
"max-procs" => 1,
"socket" => "/tmp/webcounter.socket",
"check-local" => "disable"

then, after restarting lighttpd, we can try the counter at the URL http://ip-of-your-server/fastcgi/webcounter.

Only two notes about the configuration file: the “+” in the first added line before the “=” and the line “max-procs” => “1”, that force lighttpd to execute only one instance of the FastCGI to avoid malfunctions.

References: Structure and options of the FastCGIs’ configuration file

giovedì 23 luglio 2009

Wow, Monkey Island is back!

One of my favourite games of ever!

martedì 16 giugno 2009

What you need to develop FastCGIs: my favorite tools

Besides an environment for compiling and deploying applications (in my case an Ubuntu Server distribution) there are some other useful tools that can help the developer on writing code and debugging it.
Usually, I work on Windows (at the moment I'm trying Windows 7 RC) and I execute the server on a virtual machine in the same PC.
My favorite text editor is Notepad++: free, open, fast and with a lot of useful functions for developers. When I write CSS, HTML, PHP, JS or C code I can't live without it.
To upload files to the server there are 2 great FTP/SFTP clients: WinSCP and Filezilla and it's hard to decide which is the best.
The most difficult step on developing web applications is the debugging stage, in this case we could need HttpSpy, a simple application that can capture HTTP traffic (it works only with Internet Explorer, but not under Vista), if you prefer more sophisticated tools you can consider Fiddler (I prefer simplicity so I use HttpSpy, when possible).

Another must-have tool is the YUI Compressor that can minimize JavaScript and CSS code.

There are also a lot of fantastic plug-ins for web developers that can be installed on Firefox:

Firebug: it “allows the debugging, editing, and monitoring of any website's CSS, HTML, DOM, and JavaScript, and provides other Web development tools.” (Wikipedia)

CSSViewer: a simple CSS properties viewer

Dust-me Selectors: useful to find unused CSS selectors

Venkman JavaScript Debugger: nothing else …

Google Page Speed and Yahoo! YSlow: two tools for speed-up tuning of the web site

SEO for Firefox: a good support for SEO analysis

If you know other useful tools for web developers let me know, please.

martedì 2 giugno 2009

Sorry, but what are FastCGIs?

A friend of mine asked me this question, an easy answer is that they are faster CGIs! Obviously now the question is “What are CGIs?”.

When the web was emerging there was the need to serve not only static pages, but also pages created just in time. The first, primitive answer was the Server Side Include (SSI) technology, useful to accomplish easy tasks, but inadequate to develop complex pages and sites. A better solution was the Common Gateway Interface (CGI), a standard protocol for interfacing web servers with any stand-alone application able to write to the standard output. The web server acts as a gateway: it executes the application corresponding to the called URL and sends its standard output to requesting client (the browser) over the TCP/IP connection. So, thanks to CGI, every language capable of writing to the standard output, even bash scripts, could generate dynamic web pages (not only HTML pages, but also images, style files, etc.). As you can see, differently from current languages and environments for the web (PHP, ASP.NET, JSP, etc.), the programmer have to do a hard work: he has to generate the header of the HTTP answer and, in the case of a HTML page, to compile every tag.

The CGI approach to dynamic web pages has other disadvantages: some performance problems, a difficult access to HTTP’s parameters (GET/POST parameters, cookies and other header’s parameters) and the lack of a communication mechanism between application instances. FastCGI protocol try to overcome these limits.

domenica 31 maggio 2009

Hello World Wide Web: Part 2, deploying and testing

The binary helloweb is ready, now it's time to deploy it on the lighttpd web server and test it.

First, for convenience, we could move it to a directory that we decided to reserve to fastCGIs, for example /var/fastcgi.

Second we must instruct lighttpd to recognize helloweb has a fastCGI, so vi must set it up correctly; have a look at the directory /etc/lighttpd, it contains two other directories: conf-available and conf-enabled, the first one contains a collection of possible configuration files for different modules of the web server, the second one those effectively used. All the information about fastCGIs are in the file 10-fastcgi.conf and putting a symbolic link inside the conf-enabled directory makes this files actually used (after a web service restart).

A common 10-fastcgi.conf file looks like this:

server.modules += ( "mod_fastcgi" )

fastcgi.server = ( "/fastcgi/helloweb" =>;
"bin-path" => "/var/fastcgi/helloweb",
"socket" => "/tmp/helloweb.socket",
"check-local" => "disable"

The line server.modules += ( "mod_fastcgi" ) loads the fastcgi module, the rest of the file instructs lighttpd about the usage of the fastcgi created in the previous post.
The instruction "/fastcgi/helloweb" informs the web server that an http request of URLs starting with /fastcgi/helloweb must be redirect to the fastcgi specified by the parameter "bin-path" (i.e. /var/fastcgi/helloweb).

Once modified the file, we must create a symbolic link to it in the directory conf-enabled:

ln -s /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled/10-fastcgi.conf

then we must restart the web server:

/etc/init.d/lighttpd restart

Now it's time to test the program: point your browser to the URL http://ip-of-your-server/fastcgi/helloweb where ip-of-your-server is the ip of the server running lighttpd (if you don't know your ip, simply digit ifconfig at the prompt). If everything went well an exciting ""Hello World Wide Web" will appear.

Note: I had some problem in deploying the fastcgi because initially I put "fastcgi.server =" and "( "/fastcgi" =>" in two different lines in the configuration file, joining them in a single line made everything working well.


martedì 19 maggio 2009

Hello World Wide Web: Part 1, editing and compiling

In the last posts we set up the programming environment, the web server is running and finally we are ready to start with the first FastCGI application: what better than a web version of the classic Hello World, for the occasion renamed Hello World Wide Web? Let’s go!

First we must include the library fcgi_stdio needed by every FastCGI application:

#include “fcgi_stdio.h”

This isn’t the only possibility, the library fcgiapp is an alternative. What are the differences between fcgi_stdio and fcgiapp? The fcgi_stdio library is a layer on top of the fcgiapp library that implement also CGI functionalities, so an application developed with fcgi_stdio can run indifferently in CGI or FastCGI environment without recompilation.

According to the official FastCGI site using the library fcgi_stdio is preferable because the fcgi_stdio library offers several advantages:

Simplicity: there are only 3 new API calls to learn

Familiarity: If you are converting a CGI application to FastCGI, you will find few changes between CGI and FastCGI. We designed our library to make the job of building a FastCGI application as similar as possible to that of building a CGI application: you use the same environment variables, same techniques for parsing query strings, the same I/O routines, and so on.

Convenience: the library provides full binary compatibility between CGI and FastCGI. That is, you can run the same binary as either CGI or FastCGI.

The fcgiapp library is more specific to FastCGI, without trying to provide the veneer of familiarity with CGI.

After the #include, as usual for every C program, there is the main() function:

int main( int argc, char *argv[] ) { ... }

that is composed by a while loop waiting for every HTTP requests:

while( FCGI_Accept() >= 0 ) { ... }

FCGI_Accept function accepts a new request from the HTTP server (i.e. Lighttpd) and creates a CGI-compatible execution environment for the request.

Inside this while loop we must put the real program that generate the HTTP answer. An HTTP answer to a GET or a POST request must be composed of a header and the content (differently from other most popular languages for the web it's mandatory to write the header by-hand every time).

We can easily send both, header and content, to client writing them to the standard output as any regular CGI application, so in our first example we need only two lines of code:

printf( "Content-Type: text/plain\r\n\n\n" );

for header of the HTTP answer (note that the two new-lines , "\n\n", at the end of the string conventionally mark the end of the header) and

printf( "Hello World Wide Web\n" );

that represents what will appear on the browser.

That's all.

The full code of the example is:

#include "fcgi_stdio.h"
int main( int argc, char *argv[] )

while( FCGI_Accept() >= 0 )

printf( "Content-Type: text/plain\n\n" );
printf( "Hello World Wide Web\n" );
return 0;

We can save this code with "helloweb.c" and compile it with this command:

gcc -o helloweb -lfcgi helloweb.c

In the next post we will examine how to deploy helloweb on the web server.