Common Gateway Interface

The Common Gateway Interface (CGI) is a standard protocol for interfacing external application software with an information server, commonly a web server.

The task of such an information server is to respond to requests (in the case of web servers, requests from client web browsers) by returning output. Each time a request is received, the server analyzes what the request asks for, and returns the appropriate output. The two basic methods for the server to do this are the following:

• If the request identifies a file stored on disk, then return the contents of that file.
• If the request identifies an executable command and possibly arguments, then run the command and return its output.

CGI defines a standard way of doing the second. It defines how information about the server and the request is passed to the command in the form of arguments and environment variables, and how the command can pass back extra information about the output (such as the type) in the form of headers.

History

In 1993, the World Wide Web (WWW) was small but booming. WWW software developers and web site developers kept in touch on the www-talk mailing list, so it was there that a standard for calling command line executables was agreed upon. Specifically mentioned in the CGI spec are the following contributors:

• Rob McCool (author of the NCSA HTTPd web server)
• John Franks (author of the GN web server)
• Ari Luotonen (the developer of the CERN httpd web server)
• Tony Sanders (author of the Plexus web server)
• George Phillips (web server maintainer at the University of British Columbia)

Rob McCool drafted the initial specification, and NCSA still hosts it. It was swiftly implemented in all servers.

Example

An example of a CGI program is one implementing a wiki. The user agent requests the name of an entry; the server will retrieve the source of that entry's page (if one exists), transform it into HTML, and send the result.

Implementation

From the Web server's point of view, certain locators, e.g. http://www.example.com/wiki.cgi, are defined as corresponding to a program to execute via CGI. When a request for the URL is received, the corresponding program is executed.

Data is passed into the program using environment variables. This is in contrast to typical execution, where Command-line arguments are used. In the case of HTTP PUT or POSTs, the user-submitted data is provided to the program via the standard input.^[1]

Web servers often have a cgi-bin directory at the base of the directory tree to hold executable files called with CGI.

The program returns the result to the web server in the form of standard output, prefixed by a header and a blank line.

Header format

The header is encoded in the same way as a HTTP header and must include the MIME_type of the document returned.^[2] The headers are generally forwarded with the response back to the user, supplemented by the web server.

Drawbacks

This is a low-tech approach. Calling a command generally means the invocation of a newly created process. Starting up the process can take up much more time and memory than the actual work of generating the output, especially when the program still needs to be interpreted or compiled. If the program is called often, the workload can quickly overwhelm web servers. However, this overload is negligible when using compiled CGI programs, such as those in C/C++, and only really manifests when using Perl or other scripting languages with CGI, and even then only on servers which experience a high load.

Alternatives

Several approaches can be adopted for remedying this:

• The popular Web servers developed their own extension mechanisms that allows third-party software to run inside the web server itself, e.g. Apache modules, Netscape NSAPI plug-ins, IIS ISAPI plug-ins. While these interfaces didn't reach the same standardization achieved for CGI, they were at least published and at least partly implemented on multiple web servers.

• Simple Common Gateway Interface or SCGI

• FastCGI allows a single, long-running process to handle more than one user request while keeping close to the CGI programming model, retaining the simplicity while eliminating much of the overhead CGI incurs by creating a new process for each request. Unlike converting an application to a web server plug-in, FastCGI applications remain independent of the web server.

The optimal configuration for any web application depends on application-specific details, amount of traffic, and complexity of the transaction; these tradeoffs need to be analyzed to determine the best implementation for a given task and time budget.

See also

• FastCGI
• SCGI
• WSGI
• Application server
• List of computer standards

References

External links

• The The Common Gateway Interface at NCSA
• The CGI standard at w3.org.
• RFC3875: The Common Gateway Interface (CGI) Version 1.1
• Cgicc, FSF C++ library for CGI request parsing and HTML response generation
• CGI, a standard Perl module for CGI request parsing and HTML response generation