# Common Gateway Interface The Common Gateway Interface (CGI) is a standard interface that lets an HTTP server run external programs, called gateway programs or CGI scripts, and return their output to the client, in a platform-independent manner.[1](https://www.rfc-editor.org/info/rfc3875/) It has been in use on the World-Wide Web since 1993, when the interface was developed and documented at the U.S. [National Center for Supercomputing Applications](https://www.edgepedia.org/national-center-for-supercomputing-applications) (NCSA), and it remains the mechanism behind the familiar `cgi-bin` directory convention.[1](https://www.rfc-editor.org/info/rfc3875/) • [2](https://networkencyclopedia.com/common-gateway-interface-cgi/) | Key fact | Detail | |---|---| | What it is | An interface for running external programs under an information server; the supported information servers are HTTP servers[1](https://www.rfc-editor.org/info/rfc3875/) | | Origin | Specification written in 1993 by the NCSA team on the www-talk mailing list, led by Rob McCool of NCSA HTTPd[2](https://networkencyclopedia.com/common-gateway-interface-cgi/) | | Formal specification | RFC 3875, "The Common Gateway Interface (CGI) Version 1.1", Informational, published October 2004 by D. Robinson and K. Coar of The Apache Software Foundation[1](https://www.rfc-editor.org/info/rfc3875/) | | Communication channels | Environment variables (meta-variables), the command line, standard input, and standard output[3](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/interface.html) | | Languages | Any language that produces an executable file, including C/C++, Perl, TCL, the Bourne shell, and the C shell[4](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/intro.html) | | Main cost | The server spawns a new process for each client request and kills it afterward, paying start-up overhead every time[5](https://fastcgi-archives.github.io/fcgi2/doc/fastcgi-prog-guide/ch1intro.htm) | | Principal successor | FastCGI, in which a long-lived application process persists between requests and serves many of them[5](https://fastcgi-archives.github.io/fcgi2/doc/fastcgi-prog-guide/ch1intro.htm) | ## How it works CGI divides responsibility between the server and the script. The server manages the connection, data transfer, transport, and network issues of the client request; the CGI script handles the application issues, such as data access and document processing.[1](https://www.rfc-editor.org/info/rfc3875/) The interface defines a set of abstract parameters, called meta-variables, that describe the client's request, together with a concrete programmer interface, so the same script can run under different servers.[1](https://www.rfc-editor.org/info/rfc3875/) The server and script communicate in four major ways: environment variables, the command line, standard input, and standard output.[3](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/interface.html) The meta-variables carry the request details the script needs. REQUEST_METHOD holds the HTTP method and MUST be set; QUERY_STRING contains the URL-encoded search or parameter string; CONTENT_LENGTH gives the size of the attached message-body in decimal octets and is set if and only if a body is present; PATH_INFO carries the extra path following the script name, and PATH_TRANSLATED maps that extra path onto the server's document repository; SERVER_NAME identifies the server, which can have several values when multiple HTTP virtual hosts share one [IP address](https://www.edgepedia.org/ip-address).[1](https://www.rfc-editor.org/info/rfc3875/) **Methods and data.** Under the GET method the script produces a document, and the meaning of GET may be refined by protocol-specific meta-variables. The POST method asks the script to perform processing and produce a document based on the request message-body; a common use is HTML form submission intended to initiate processing with a permanent effect, such as a change in a database. A script using POST MUST check CONTENT_LENGTH before reading the attached body and SHOULD check CONTENT_TYPE before processing it.[1](https://www.rfc-editor.org/info/rfc3875/) Request data is read by a system-defined method, by default the standard input file descriptor.[1](https://www.rfc-editor.org/info/rfc3875/) **Responses.** The script writes its response to standard output. Status code 200 (OK) indicates success and is the default for a document response; 302 (Found) is used with a Location header field and a response body.[1](https://www.rfc-editor.org/info/rfc3875/) Unless the implementation defines otherwise, the script MUST NOT indicate that the client can send further requests over the same connection.[1](https://www.rfc-editor.org/info/rfc3875/) ## History In 1993 the NCSA team wrote the specification for calling command-line executables on the www-talk mailing list, with Rob McCool taking the lead as a follow-on to his work on NCSA HTTPd, one of the first web servers. Other web server developers adopted the interface, and it has been a standard for web servers since then.[2](https://networkencyclopedia.com/common-gateway-interface-cgi/) NCSA released HTTPd in 1993, and that server powered most of the early internet; the Apache project later formed around it and used HTTPd as the foundation of the [Apache HTTP Server](https://www.edgepedia.org/apache-http-server).[6](https://www.ncsa.illinois.edu/about/history/) Formalization came slowly. A work group chaired by Ken Coar started in November 1997 to give the NCSA definition a more formal status, and this work resulted in RFC 3875, which specifies CGI Version 1.1.[2](https://networkencyclopedia.com/common-gateway-interface-cgi/) The RFC is Informational rather than an Internet standard; the IESG note states that the document is not a candidate for any level of [Internet Standard](https://www.edgepedia.org/internet-standard) and was published at the [RFC Editor](https://www.edgepedia.org/rfc-editor)'s discretion.[1](https://www.rfc-editor.org/info/rfc3875/) An earlier draft update of the specification, "The WWW Common Gateway Interface Version 1.1" by [David Robinson](https://www.edgepedia.org/david-robinson), dates from 16 October 1995.[7](https://www.w3.org/CGI/) ## Uses A gateway program handles an information request and returns an appropriate document, or generates a document on the fly. This lets a server serve information not in a form the client can read, such as an SQL database, by acting as a gateway between the two.[4](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/intro.html) CGI is typically used with HTML forms to build database applications, and form handlers remain a common use: a `
` tag names a CGI program, such as a Perl script in the `cgi-bin` directory, that processes the submitted data.[7](https://www.w3.org/CGI/) • [2](https://networkencyclopedia.com/common-gateway-interface-cgi/) Early examples included converting system manual pages to HTML on the fly, interfacing with WAIS and archie databases, and collecting user feedback through forms.[4](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/intro.html) ## Server configuration and security On the Apache HTTP Server, CGI support is provided by two modules: `mod_cgi`, which runs CGI programs directly from within the server process and is used with non-threaded MPMs such as prefork or on Windows, and `mod_cgid`, which uses a dedicated external daemon to manage CGI processes and is required under threaded MPMs such as event or worker.[8](https://d.apache.org/docs/current/en/howto/cgi.html) The `ScriptAlias` directive designates a directory whose contents are all treated as CGI programs; alternatively, CGI can be enabled in arbitrary directories by activating the `cgi-script` handler and setting `Options +ExecCGI`.[8](https://d.apache.org/docs/current/en/howto/cgi.html) CGI scripts run with the permissions of the web server user and can execute essentially arbitrary commands, so they are dangerous if not carefully checked; all scripts on a server run as the same user and can conflict with one another.[9](https://d.apache.org/docs/trunk/misc/security_tips.html) Apache's suEXEC feature, included since Apache 1.2, is a setuid wrapper that runs CGI and SSI programs under user IDs different from the web server's, after a strict series of security checks.[9](https://d.apache.org/docs/trunk/misc/security_tips.html) • [10](https://d.apache.org/docs/trunk/en/suexec.html) Limiting CGI to special script-aliased directories gives the administrator control over what goes into them, and most sites choose this option.[9](https://d.apache.org/docs/trunk/misc/security_tips.html) RFC 3875's security considerations address the same concerns at the protocol level. The specification places no limits on the length of the message-body presented to the script and warns that a fixed-length buffer without careful overflow checking can expose stack-smashing or stack-overflow vulnerabilities; scripts should spool large submissions or return error statuses such as 413 (Request Entity Too Large).[1](https://www.rfc-editor.org/info/rfc3875/) Servers should not pass sensitive header fields such as [Authorization](https://www.edgepedia.org/authorization) to the script without careful consideration, confidential data should travel in a POST message-body rather than in the URI, and servers should resolve `..` path segments before splitting the request URI.[1](https://www.rfc-editor.org/info/rfc3875/) ## Performance and successors The defining cost of CGI is process lifetime. Each time a client requests a CGI application, the server asks the operating system to spawn a new process, and after the process satisfies the request the server kills it; a short-lived application therefore pays start-up overhead on every request, which is especially inefficient for programs with heavy initialization such as opening a database, or for Perl programs whose interpreter reads the entire program before executing any of it.[5](https://fastcgi-archives.github.io/fcgi2/doc/fastcgi-prog-guide/ch1intro.htm) FastCGI was designed as a replacement: the server spawns the FastCGI process once, and it continues to run and satisfy client requests until explicitly terminated, spreading start-up overhead over many requests and allowing state to persist between calls.[5](https://fastcgi-archives.github.io/fcgi2/doc/fastcgi-prog-guide/ch1intro.htm) An experimental comparison of dynamic page generation technologies by Bhupesh Kothari and Mark Claypool, a computer scientist at [Worcester Polytechnic Institute](https://www.edgepedia.org/worcester-polytechnic-institute), presented at the International Network Conference in July 2000, found that CGI and FastCGI performed effectively the same under most low-level benchmarks while Servlets performed noticeably worse.[11](https://web.cs.wpi.edu/~claypool/papers/cgi-perf/) CGI's language independence was part of its original appeal: it does not require the language itself to support the web, and any program obeying the gateway contract could serve a request.[4](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/intro.html) • [12](https://www.codehistory.org/networks-internet-the-web/cgi-and-the-moment-web-servers-began-running-programs/) The interface has receded as embedded and persistent alternatives such as mod_php, mod_perl, and FastCGI took over high-traffic serving, but it remains supported in current servers; Apache's tutorial still documents setting it up, and the RFC 3875 specification remains the current CGI specification.[8](https://d.apache.org/docs/current/en/howto/cgi.html) Tooling around it has moved on: Python's standard-library `cgi` module, long used for CGI form parsing, was deprecated in Python 3.11 and removed in Python 3.13.[8](https://d.apache.org/docs/current/en/howto/cgi.html) ## References 1. [RFC 3875: The Common Gateway Interface (CGI) Version 1.1, D. Robinson and K. Coar, October 2004, RFC Editor](https://www.rfc-editor.org/info/rfc3875/) 2. [Common Gateway Interface (CGI), Network Encyclopedia](https://networkencyclopedia.com/common-gateway-interface-cgi/) 3. [The Common Gateway Interface Specification (CGI/1.0), NCSA httpd Development Team](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/interface.html) 4. [Introduction to the Common Gateway Interface, NCSA](https://www6.uniovi.es/~antonio/ncsa_httpd/cgi/intro.html) 5. [FastCGI Programmer's Guide, Chapter 1: The Fast Common Gateway Interface](https://fastcgi-archives.github.io/fcgi2/doc/fastcgi-prog-guide/ch1intro.htm) 6. [A Legacy of Innovation, NCSA History](https://www.ncsa.illinois.edu/about/history/) 7. [CGI: Common Gateway Interface, W3C](https://www.w3.org/CGI/) 8. [Apache HTTP Server Tutorial: Dynamic Content with CGI, Version 2.4](https://d.apache.org/docs/current/en/howto/cgi.html) 9. [Security Tips, Apache HTTP Server documentation](https://d.apache.org/docs/trunk/misc/security_tips.html) 10. [suEXEC Support, Apache HTTP Server documentation](https://d.apache.org/docs/trunk/en/suexec.html) 11. [Performance Analysis of Dynamic Web Page Generation Technologies, B. Kothari and M. Claypool, INC 2000](https://web.cs.wpi.edu/~claypool/papers/cgi-perf/) 12. [CGI and the Moment Web Servers Began Running Programs, CodeHistory](https://www.codehistory.org/networks-internet-the-web/cgi-and-the-moment-web-servers-began-running-programs/) --- *Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › HTTP and web communication protocols* *Initially written Sep 17, 2026 · Reviewed: Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026* *Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.* License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license