FastCGI

FastCGI is a protocol for interfacing interactive programs with a web server.

FastCGI is a variation of the well-known Common Gateway Interface (CGI).

The main goal of FastCGI is to reduce the load associated with interfacing web server and Common Gateway Interface programs, allowing one server to serve more requests at once.

Advantages

• Independence of language used. Freedom of choice of development platform: C++, PHP, Python, Perl, Java, among others.
• A separate process is used. Freedom of choice of the web server. Facility for the treatment of errors and depuration.
• Separate host execution is possible. Increased freedom for system configuration, both in network design and in the choice of operating systems. Decrease in the workload of the main server.

In short, the design freedom of CGI at the speed of a server module.

History

CGI is a protocol for interfacing external applications with web servers. CGI applications run in a separate process that is created at the start of each request and is terminated when its work is done. This model of "a new process for each request" makes CGI programs very easy to implement, but limits efficiency and scalability. At high loads, the overhead on the operating system from process creation and destruction becomes significant and limits scalability. In addition, the CGI process model limits resource reuse techniques (such as database connection reuse, in-memory caching, etc).

To address the scalability problem of CGI, Open Market developed FastCGI and first introduced it in its web service product in the mid 90's. Open Market originally developed FastCGI in part as a competitive response to Netscape's then-in-progress proprietary NSAPI API for developing Web applications.

Although initially developed by the Open Market, FastCGI was implemented by other web service vendors. FastCGI, however, competed against other techniques that also tried to increase speed and simplify server-side communications, but did not follow the CGI paradigm. Modules for Apache such as mod perl and mod php appeared around the same time and seemed to be better replacements for CGI, allowing very close integration with the core web server.

Implementation details

Instead of creating new processes for each request, FastCGI can use a single persistent process that handles any request during its lifetime. Processing multiple requests at the same time is accomplished either by using a single connection with internal multiplexing (eg multiple requests on a single connection) and/or by using multiple connections. Several of those processes can exist, and that is something that increases scalability and performance. FastCGI also allows programs to make the web server perform certain simple operations, such as reading a file before the request is processed. Environment variables and page requests are sent from the web server to processes through a TCP connection (for remote processes) or through Unix sockets (for local processes). Responses are returned from the process to the web server over the same connection. The connection may be closed at the end of a response, but the web server and the process are kept running.

Several web site administrators and programmers found that the separation of web applications from the web server produced by FastCGI (and the simplicity of SCGI) had many advantages over embedded interpreters (mod perl, mod php, etc). This separation allows server and application processes to be restarted independently; an important consideration to take into account in very busy websites. This also makes it easy to apply security policies on a per-application basis; important thing for ISPs and web hosting companies.

Web servers that implement FastCGI

Note: unless otherwise reported, until now it is not known when the FastCGI implementation will be completed

• Abyss Web Server
• Apache HTTP Server (partial)
  • Implemented by mod_fcgid. This module was of third parties, but it was guaranteed that it would be an Apache subproject in 2009, led by Chris Darroch
  • The outdated module of third mod_fastcgi is also being used
  • Multiplexed requests through a single connection is prohibited by Apache design, so it is not supported in Apache
• Cherokee HTTP Server
• Hiawatha webserver
  • Load balance support for FastCGI
  • FastCGI server support with root cage
• Lighttpd
• Monkey Web Server
• LiteSpeed Web Server
• Microsoft IIS
• Kerio WebSTAR
• Nginx
• Open Market Web Server
• Resin Application Server
• Roxen Web Server
• Sun Java System Web Server
• Any Servlet container (such as Apache Tomcat or Jetty), using the JFastCGI library.
• Zeus Web Server
• My server project

'Bindings' of languages for the FastCGI API

FastCGI can be implemented in any language that supports sockets. The API exists to:

• Borland Delphi/FreePascal
• C
• C++
• Chicken Scheme
• Common Lisp: CLISP and CMUCL
• D
• Guile Scheme
• Eiffel
• Haskell
• HP BASIC for OpenVMS
• Java
• Lua
• OCaml
• XSP
• Perl
• PHP
• Roadsend PHP
• Python
• Ruby
• SmallEiffel
• Smalltalk: FasTalk and Dolphin Smalltalk
• TCL

FastCGI enabled portability to web applications; in contrast, applications that were developed for embedded interpreters (such as mod python) are generally very limited to the Apache API. Recent frameworks such as Ruby on Rails, Kepler (etc...) allow the use of any of the embedded interpreters (mod ruby, mod perl, mod python or mod_lual, respectively), but also FastCGI. This trend appears to be set to continue.

Libraries that include support for FastCGI

• qDecoder
• GNU Cgicc