4. Developing web applications with Apache

There are several ways of providing content with Apache.

Related talk

• W07: Web Application Technologies - surveying the landscape

4.1 Static

Apache can serve static content, like HTML files, images, etc. If this is all you need, Apache is probably right for you. A low end Pentium running Linux and Apache can easily saturate a 10Mbps line serving static content. If that is your primary use of Apache, make sure you also check the performance section.

4.2 Dynamic content

For many websites, the information changes constantly and pages need to be updated periodically or generated on the fly. This is what server side programming is all about: programming languages, tools and frameworks that help developers query and modify information from different sources (databases, directory services, customer records, other websites) and deliver the content to the user.

4.3 CGI scripts

CGI stands for Common Cateway Interface. CGI scripts are external programs that are called when a user requests a certain page. The CGI receives information from the web server (forms variable values, type of browser, IP address of the client, etc) and uses that information to output a web page for the client.

Pros: Since it is an external program, it can be coded any language and the same script will also be portable among different web servers. The CGI protocol is simple, and the return result consists of writing the response to the standard output. It is a mature technology, and there are plenty of online and book references and examples.

Cons: Spawning and initializing a process takes time. Since a CGI is external to the server and an instance has to be launched/destroyed for every request there is a performance hit. If the process has to load external libraries or perform a connection to an external database the delay can be important. Same thing if the number of hits per second is high. CGIs are stateless and session management has to be achieved by external means.

Since CGI usually involves heavy text manipulation, scripting languages are the natural choice. Part of Perl popularity stems from being the CGI programming language of choice. This is due to its extensive support for string handling and text processing. There are plenty of freely available CGI scripts and libraries. A good starting point is: the Open Directory CGI section

4.4 Site generators

If your site is high volume, you may run into performance problems when generating content dynamically. Offline content generators are an alternative. These solutions separate content from presentation. The HTML generator reads both sources and outputs the static files that build the website. The generator can be run periodically or triggered by content changes.

Future versions of Cocoon plan on having a batch mode to accomplish this. Another option is the Web site meta language.

4.5 Out of process servers

The web server can pass dynamic requests to another program. This program sits idle until a request comes. The request is processed and returned to the webserver which in turn returns it to the client. This eliminates the overhead associated with CGI scripts. Examples of this approach are Fast CGI, Java servlets, etc.

4.6 Fast CGI

This standard was developed to address some shortcomings of the CGI protocol. The main improvement is that a single spawned process can process more than one request. There is an Apache module that implements the Fast CGI protocol and libraries for Tcl, Perl etc. More information at http://www.fastcgi.com

Related talk

• F18: FastCGI -- The forgotten treasure

4.7 Java servlets

An external Java virtual machine processes requests. The JVM can reside in the same computer or in a different one. This is how a lot of application servers work. Usually standard libraries are included for server side processing. You want to check JServ and Tomcat. Related Java application server projects can be found here

Related talk

• W16: Recommendations for Java-Based Web Application Architectures

4.8 Embeded interpreters

An alternative to out-of-process webservers is to embed the interpreter in the server itself. There are roughly two categories in this kind of modules: Modules that answer or modify requests directly and modules aimed to process commands embeded in HTML pages before serving it to the client. The most representative approaches are mod_perl and PHP