Mark R. Brown

Open Market, Inc.

2 May 1996

Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.

Abstract

FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI without introducing any of the new problems associated with writing applications to lower-level Web server APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including applications written in popular scripting languages such as Perl), supporting both single-threaded and multi-threaded application programming, supporting distributed configurations for scaling and high availability, and generalizing the roles that gateway applications can play beyond CGI’s “responder” role.

For more information on FastCGI, including an interface specification and a module for the Apache server, visit the fastcgi-archives.github.io Web site.

1. Introduction

The surge in the use of the Web by business has created great demand for applications that create dynamic content. These applications allow businesses to deliver products, services, and messages whose shape and content are influenced by interaction with and knowledge of users.

This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not all) of the performance problems with CGI, but are not designed to meet the need of business applications. When applied to business applications, Web server APIs suffer from these problems:

Web server APIs are suitable for applications that require an intimate connection to the core Web server, such as security protocols. But using a Web server API for a Web business application would be much like using an old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior performance to boot. Nobody uses the old technology unless they are already locked into it.

FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI’s performance problems. The major implementation differences are:

FastCGI communicates the exact same information as CGI in a different way. Because FastCGI is CGI, and like CGI runs applications in separate processes, it suffers none of the server API problems listed above.

2. Migration from CGI

Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the protocol details from the developer. This library, which is freely available, makes writing FastCGI programs as easy as writing CGI applications.

The application library provides replacements for the C language standard I/O (stdio) routines such as printf() and gets(). The library converts references to environment variables, standard input, standard output, and standard error to the FastCGI protocol. References to other files “fall through” to the underlying operating system standard I/O routines. This approach has several benefits:

Here’s a simple FastCGI application:

    #include <fcgi_stdio.h>

    void main(void)
    {
        int count = 0;
        while(FCGI_Accept() >= 0) {
            printf("Content-type: text/html\r\n");
            printf("\r\n");
            printf("Hello world!<br>\r\n");
            printf("Request number %d.", count++);
        }
        exit(0);
    }

This application returns a “Hello world” HTML response to the client. It also keeps a counter of the number of times it has been accessed, displaying the value of the counter at each request. The fcgi_stdio.h header file provides the FastCGI replacement routines for the C standard I/O library. The FCGI_Accept() routine accepts a new request from the Web server.

The application library was designed to make migration of existing CGI programs as simple as possible. Many applications can be converted by adding a loop around the main request processing code and recompiling with the FastCGI application library. To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.

Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix platforms are available from the fastcgi-archives.github.io Web site. The interpreters are backward-compatible: They can run standard Tcl and Perl applications.

3. Single-threaded and multi-threaded applications

FastCGI gives developers a free choice of whether to develop applications in a single-threaded or multi-threaded style. The FastCGI interface supports multi-threading in two ways:

Multi-threaded programming is complex – concurrency makes programs difficult to test and debug – so many developers will prefer to program in the familiar single-threaded style. By having several concurrent processes running the same application it is often possible to achieve high performance with single-threaded programming.

The FastCGI interface allows Web servers to implement session affinity, a feature that allows applications to maintain caches of user-related data. With session affinity, when several concurrent processes are running the same application, the Web server routes all requests from a particular user to the same application process. Web server APIs don’t provide this functionality to single-threaded applications, so the performance of an API-based application is often inferior to the performance of the corresponding FastCGI application.

4. Distributed FastCGI

Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to systems that don’t have Web servers.

Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can communicate through the firewall to internal databases. For instance, an application might need to authenticate incoming users as customers in order to give access to certain documents on the external Web site. With FastCGI this authentication can be done without replicating data and without compromising security.

5. Roles

A problem with CGI is its limited functionality: CGI programs can only provide responses to requests. FastCGI provides expanded functionality with support for three different application “roles”:

Other roles will be defined in the future. For instance, a “logger” role would be useful, where the FastCGI program would receive the server’s log entries for real-time processing and analysis.

6. Conclusions

Today’s Web business applications need a platform that’s fast, open, maintainable, straightforward, stable, and secure. FastCGI’s design meets these requirements, and provides a logical migration path from the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI’s benefits without losing their existing investment in CGI applications.

For more information about FastCGI, visit the fastcgi-archives.github.io Web site.

© Copyright 1996 - 2014 Open Market, Rob Saccoccio & others, All rights reserved.