Common Gateway Interface

Common Gateway Interface
Name	Common Gateway Interface
Status	Superseded
Year started	1993
Year ended	c. late 1990s
Influenced by	NCSA HTTPd
Influenced	FastCGI, PHP, Apache HTTP Server

Common Gateway Interface. It is a standard protocol that enables web server software to delegate the generation of web pages to executable programs. Developed in the early 1990s, it was instrumental in transforming the World Wide Web from a collection of static documents into a platform for dynamic, interactive applications. While largely superseded by more modern technologies, its design principles directly influenced the development of server-side scripting and web application frameworks.

Overview

The specification was created around 1993 by a team at the National Center for Supercomputing Applications who were also responsible for the pioneering Mosaic browser. Its primary purpose was to provide a reliable method for the NCSA HTTPd server to pass information from an HTTP request to an external program and return the program's output to the client. This mechanism allowed for the creation of dynamic content, such as processing form data from HTML pages or querying database systems like Oracle Database. The protocol's design was intentionally simple and language-agnostic, meaning programs could be written in Perl, C, Unix shell, or virtually any language capable of reading from standard streams.

Technical details

Communication occurs through a set of environment variables and standard input/standard output streams. When a request is received, the web server prepares a specific set of environment variables containing details about the request, such as `REQUEST_METHOD` (e.g., GET or POST) and `QUERY_STRING`. For `POST` requests, the message body is passed to the executable via its standard input. The executable then runs, generates output—typically beginning with a minimal HTTP header—and writes it to standard output. The server reads this output and relays it back to the client's web browser. This model treats each request as triggering a new operating system process, which has significant implications for performance and resource management.

Operation

In a typical deployment, a system administrator configures the web server to recognize certain directories, often named `/cgi-bin/`, as containing executable programs. When a user submits a form or visits a corresponding URL, the server executes the designated program. For instance, an early search engine might use a program to parse query parameters, search an index, and format the results into an HTML page. Another classic use was for website hit counters or guestbook applications that would read from and write to a simple text file. The server itself does not interpret the program's code; it merely acts as a gateway, managing the execution environment and data flow between the Internet and the backend executable.

Examples

Early dynamic websites heavily relied on this technology for interactive features. A canonical example is a form handler written in Perl that would email the contents of a feedback form to a site administrator. Many early implementations of shopping cart software for e-commerce were built using it to manage user sessions and product databases. The famous Yahoo! directory, in its initial stages, utilized such programs to manage its curated listings. Scripts written for the Unix shell were often used for simple tasks like displaying the current server time or system status, embedding the output directly into a webpage.

Security considerations

The model introduced several well-documented security risks. Because it executes external programs, a primary concern is ensuring that user-supplied data from forms or URL parameters is meticulously validated to prevent command injection attacks. Poorly written scripts could allow an attacker to execute arbitrary commands on the server. The process creation overhead for each request also opened the door to denial-of-service attacks by exhausting system resources. These concerns prompted stricter server configurations, the development of more secure programming practices in languages like Perl, and ultimately motivated the creation of more integrated and secure alternatives within web servers like the Apache HTTP Server.

Alternatives and legacy

Performance and security limitations led to the development of more efficient alternatives. FastCGI was created as a persistent, long-lived process protocol to reduce overhead. Major technologies like PHP, Java Servlets (running on Apache Tomcat), and Microsoft's Active Server Pages (ASP) integrated more tightly with the web server, offering better performance and simpler development. Today, modern web application frameworks such as Django, Ruby on Rails, and Node.js have largely rendered the original interface obsolete. However, its conceptual architecture established the fundamental client-server-database pattern that underpins virtually all contemporary web applications and cloud computing services.

Category:Web server management Category:Internet protocols Category:World Wide Web Consortium standards