Getting started with CGI: how the Common Gateway Interface works

What the web server does when a CGI request arrives

The server identifies the request as CGI when the URL matches a cgi-bin directory or a .cgi/.pl extension (depending on configuration). It then sets a collection of environment variables: REQUEST_METHOD (GET or POST), QUERY_STRING (the part after ? for GET requests), CONTENT_LENGTH and CONTENT_TYPE (for POST), HTTP_* variables for each request header, PATH_INFO, SERVER_NAME, REMOTE_ADDR, and others. The request body for POST requests is available on the program's standard input. The program reads these, does its work, and prints the response to standard output, starting with HTTP headers.

The main performance characteristic of CGI is that every request forks a new process and loads the interpreter from scratch. A Perl or Python interpreter startup takes tens to hundreds of milliseconds, which is fine for low-traffic uses but adds up under load. FastCGI and WSGI address this by keeping the interpreter process alive between requests; the protocol differences are covered in the modern alternatives guide.

The CGI environment variables

The CGI standard defines a set of environment variables the server must set before invoking the script. The most commonly used ones are: REQUEST_METHOD (GET, POST, HEAD), QUERY_STRING (URL-decoded query parameters for GET), CONTENT_LENGTH (byte count of the POST body), CONTENT_TYPE (MIME type of the POST body, e.g. application/x-www-form-urlencoded), HTTP_HOST (the Host header), HTTP_REFERER (the Referer header), REMOTE_ADDR (client IP), SERVER_NAME (the hostname of the server), SCRIPT_NAME (the CGI script's URL path), and PATH_INFO (additional path information after the script name).

All HTTP request headers arrive as HTTP_* variables with hyphens replaced by underscores and names uppercased: the Accept-Language header becomes HTTP_ACCEPT_LANGUAGE. Under Perl's taint mode, all of these variables are tainted and must be explicitly validated before use. Under any language, treat all of them as untrusted user-controlled input.

Where CGI still fits in 2026

CGI is no longer the dominant model for web application development; frameworks, containers, and serverless functions handle most of what CGI once did. But CGI is still present and still appropriate in specific contexts. Shared hosting environments that do not offer PHP or Node.js often support CGI as the only way to run dynamic code. Legacy systems built around CGI scripts may not justify a full migration. Simple administrative scripts and internal tools benefit from the simplicity of CGI without needing a full application server.

Understanding CGI is also useful for debugging and for understanding how the web worked before application servers, since many concepts (environment-based request passing, stdout as response, process isolation per request) reappear in different forms in modern serverless and container architectures. For new projects, evaluate whether a modern alternative fits before defaulting to CGI, but do not mistake familiarity with better for actual technical superiority in every context.