Common Gateway Interface
The early Web resembled an immense frozen library. Consulting a page was like leafing through a book: one could read, but interaction was impossible. This situation changed radically a few years later when users began demanding more. They wanted to fill out forms, search for information, personalize their experience. Static pages were already reaching their limits.
Rob McCool worked at the National Center for Supercomputing Applications on the NCSA HTTPd web server. In 1993, he conceived an elegant solution to this problem: creating a bridge between the web server and external programs. This idea gave birth to the Common Gateway Interface, better known by the acronym CGI. The term gateway perfectly reflected its purpose: connecting two previously separate worlds.
The genius of CGI lay in its simplicity. When a visitor clicked a link or submitted a form, the server no longer simply returned an existing file. It launched a program on the server that generated a customized response, then transmitted this response to the browser. Suddenly, the Web came alive. Developers could write their scripts in the language of their choice, provided it respected a few basic rules.
These rules defined a standardized communication protocol. The server transmitted request information via environment variables called meta-variables. The script retrieved this data, processed it, and generated a response conforming to the HTTP protocol. This universal approach worked with any programming language, from C to Python to Perl.
Perl indeed became CGI’s champion. Its ability to manipulate text, its permissive syntax, and its availability on all platforms won over web developers. The first scripts processed HTML forms, queried databases, and assembled personalized pages. It was an era of experimentation.
These experiments gave rise to collections of shared scripts. Matt Wright, a high school student in Colorado, created “Matt’s Script Archive” in 1995, which became an essential reference. His FormMail script allowed form content to be sent by email and was downloaded thousands of times. Problem: Wright was young, inexperienced, and his scripts contained glaring security flaws. The Perl community responded by creating “Not Matt’s Scripts”, offering more robust alternatives.
For security posed a constant challenge. Each CGI script represented a potential gateway into the system. Developers had to scrupulously validate input data, avoid buffer overflows, and guard against malicious code injection. Administrators generally confined these scripts to a special directory, the famous cgi-bin, to limit damage in case of problems.
CGI’s architecture suffered from a congenital defect: each request triggered the launch of a new process. On a lightly trafficked server, this went unnoticed. But as soon as traffic increased, performance collapsed. The machine spent more time creating and destroying processes than actually handling the requests themselves.
Solutions emerged to work around this limitation. FastCGI kept processes alive between requests, eliminating the startup overhead. Mod_perl integrated the Perl interpreter directly into Apache, transforming scripts into persistent modules. These optimizations gave CGI a new lease on life.
Meanwhile, other approaches gained ground. PHP, created in 1994 by Rasmus Lerdorf, offered native integration with the web server. No more external processes needed: code executed directly within Apache. Microsoft developed ASP for its IIS servers, while Sun worked on JSP for the Java universe. Each sought their path toward dynamic web programming.
These new technologies did not erase CGI’s legacy. They adopted its fundamental concepts: separation between server and application logic, information transmission via the environment, request-response model. CGI had blazed the trail, others were widening it.
Evolution accelerated at the turn of the 2000s. Modern web frameworks brought higher-level abstractions, sophisticated state management, service-oriented architectures. Ruby on Rails revolutionized web development in 2004, Django did the same for Python. These tools rendered CGI obsolete for most uses.
Yet CGI refused to disappear completely. Its official standardization in RFC 3875 in 2004 recognized its historical importance. This specification codified ten years of practical experience, detailing every technical aspect of the interface. Apache and other servers continued supporting it, preserving compatibility with legacy applications.
This longevity is explained by the robustness of CGI’s conceptual model. The idea of a standard interface between web server and external programs remains relevant today. Modern microservices architectures and REST APIs take up this principle on a larger scale, including the stateless philosophy.