World Library  
Flag as Inappropriate
Email this Article

Common Gateway Interface

Article Id: WHEBN0000007220
Reproduction Date:

Title: Common Gateway Interface  
Author: World Heritage Encyclopedia
Language: English
Subject: PHP, FastCGI, Perl, PSGI, Mod wsgi
Collection: Servers (Computing), Web Technology, World Wide Web
Publisher: World Heritage Encyclopedia

Common Gateway Interface

Common Gateway Interface (CGI) is a standard method used to generate dynamic content on Web pages and Web applications. CGI, when implemented on a Web server, provides an interface between the Web server and programs that generate the Web content. These programs are known as CGI scripts or simply CGIs; they are usually written in a scripting language, but can be written in any programming language.


  • History 1
  • Overview 2
  • Syntax 3
  • Deployment 4
  • Uses 5
  • Alternatives 6
  • See also 7
  • References 8
  • External links 9


In 1993, The NCSA team wrote the specification for calling command line executables on the www-talk mailing list. ;[1] however, NCSA no longer hosts this.[2][3] The other Web server developers adopted it, and it has been a standard for Web servers ever since. A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined.[4] This work resulted in RFC 3875, which specified CGI Version 1.1. Specifically mentioned in the RFC are the following contributors:[5]


Each Web server runs HTTP server software, which responds to requests from Web browsers. Generally the HTTP server has a directory (folder), which is designated as a document collection — files that can be sent to Web browsers connected to this server.[6] For example, if the Web server has the domain name, and its document collection is stored at /usr/local/apache/htdocs in the local file system, then the Web server will respond to a request for by sending out the (pre-written) file at /usr/local/apache/htdocs/index.html.

CGI extends this system by allowing the owner of the Web server to designate a directory within the document collection as containing executable scripts (or binary files) instead of pre-written pages; this is known as a CGI directory. For example, /usr/local/apache/htdocs/cgi-bin could be designated as a CGI directory on the Web server. If a Web browser requests a URL that points to a file within the CGI directory (e.g.,, then, instead of simply sending that file (/usr/local/apache/htdocs/cgi-bin/ to the Web browser, the HTTP server runs the specified script and passes the output of the script to the Web browser. That is, anything that the script sends to standard output is passed to the Web client instead of being shown on-screen in a terminal window.

The CGI system also allows the Web browser to send information to the script via the URL or an HTTP POST request. If a slash and additional directory name(s) are appended to the URL immediately after the name of the script, then that path is stored in the PATH_INFO environment variable before the script is called. If parameters are passed to the script via an HTTP POST or GET request (e.g., a question mark appended to the URL, followed by param=value pairs), then those parameters are stored in the QUERY_STRING environment variable before the script is called. The script can then read these environment variables and adapt to the Web browser's request.


The following CGI program shows all the environment variables passed by the Web server:



printenv — a CGI program that just prints its environment

print "Content-type: text/plain\r\n\r\n";

for my $var ( sort keys %ENV ) {
 printf "%s = \"%s\"\r\n", $var, $ENV{$var};

If a Web browser issues a request for the environment variables at, a 64-bit Microsoft Windows web server running cygwin returns the following information:

 DOCUMENT_ROOT="C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs"
 HTTP_ACCEPT_ENCODING="gzip, deflate"
 HTTP_USER_AGENT="Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0"
 PATH_TRANSLATED="C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\foo\bar"
 SCRIPT_FILENAME="C:/Program Files (x86)/Apache Software Foundation/Apache2.2/cgi-bin/"
 SERVER_ADMIN="(server admin's email address)"
 SERVER_SOFTWARE="Apache/2.2.19 (Win32) PHP/5.2.17"

From the environment, it can be seen that the Web browser is Firefox running on a Windows 7 PC, the Web server is Apache running on a system that emulates Unix, and the CGI script is named cgi-bin/

The program could then generate any content, write that to standard output, and the Web server will transmit it to the browser.

The following are environment variables passed to CGI programs:

  • Server specific variables:
  • Request specific variables:
    • SERVER_PROTOCOL: HTTP/version.
    • SERVER_PORT: TCP port (decimal).
    • REQUEST_METHOD: name of HTTP method (see above).
    • PATH_INFO: path suffix, if appended to URL after program name and a slash.
    • PATH_TRANSLATED: corresponding full path as supposed by server, if PATH_INFO is present.
    • SCRIPT_NAME: relative path to the program, like /cgi-bin/script.cgi.
    • QUERY_STRING: the part of URL after ? character. The query string may be composed of *name=value pairs separated with ampersands (such as var1=val1&var2=val2...) when used to submit form data transferred via GET method as defined by HTML application/x-www-form-urlencoded.
    • REMOTE_HOST: host name of the client, unset if server did not perform such lookup.
    • REMOTE_ADDR: IP address of the client (dot-decimal).
    • AUTH_TYPE: identification type, if applicable.
    • REMOTE_USER used for certain AUTH_TYPEs.
    • REMOTE_IDENT: see ident, only if server performed such lookup.
    • CONTENT_TYPE: Internet media type of input data if PUT or POST method are used, as provided via HTTP header.
    • CONTENT_LENGTH: similarly, size of input data (decimal, in octets) if provided via HTTP header.
    • Variables passed by user agent (HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, HTTP_USER_AGENT, HTTP_COOKIE and possibly others) contain values of corresponding HTTP headers and therefore have the same sense.

The program returns the result to the Web server in the form of standard output, beginning with a header and a blank line.

The header is encoded in the same way as an HTTP header and must include the MIME type of the document returned.[7] The headers, supplemented by the Web server, are generally forwarded with the response back to the user.


A Web server that supports CGI can be configured to interpret a URL that it serves as a reference to a CGI script. A common convention is to have a cgi-bin/ directory at the base of the directory tree and treat all executable files within this directory (and no other, for security) as CGI scripts. Another popular convention is to use filename extensions; for instance, if CGI scripts are consistently given the extension .cgi, the web server can be configured to interpret all such files as CGI scripts. While convenient, and required by many prepackaged scripts,it opens the server to attack if a remote user can upload executable code with the proper extension.

In the case of HTTP PUT or POSTs, the user-submitted data are provided to the program via the standard input. The Web server creates a subset of the environment variables passed to it and adds details pertinent to the HTTP environment.


An example of a CGI program is one implementing a Wiki. The user agent requests the name of an entry; the Web server executes the CGI; the CGI program retrieves the source of that entry's page (if one exists), transforms it into HTML, and prints the result. The web server receives the input from the CGI and transmits it to the user agent. If the "Edit this page" link is clicked, the CGI populates an HTML textarea or other editing control with the page's contents, and saves it back to the server when the user submits the form.


Calling a command generally means the invocation of a newly created process on the server. Starting the process can consume 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 command is called often, the resulting workload can quickly overwhelm the server.

The overhead involved in interpretation may be reduced by using compiled CGI programs, such as those in C/C++, rather than using Perl or other interpreted languages. The overhead involved in process creation can be reduced by techniques such as FastCGI that "prefork" interpreter processes, or by running the application code entirely within the server, using extension modules such as mod_php.

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, such as Apache modules, NSAPI plugins and ISAPI plugins.
  • 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 the overhead of 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.
  • Replacement of the architecture for dynamic websites can also be used. This is the approach taken by Java EE, which runs Java code in a Java servlet container in order to serve dynamic content and optionally static content. This approach replaces the overhead of generating and destroying processes with the much lower overhead of generating and destroying threads, and also exposes the programmer to the library that comes with Java Platform, Standard Edition on which the version of Java EE in use is based.

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


  1. ^ mailing list, Sun, 14 Nov 1993 19:24:47 -0600www-talk, by Rob McCool, Server Scripts
  2. ^ The Common Gateway Interface, archived from the original on 2010-01-27 
  3. ^ CGI: Common Gateway Interface at
  4. ^ Common Gateway Interface RFC Project Page
  5. ^ RFC3875: The Common Gateway Interface (CGI) Version 1.1
  6. ^ Mapping URLs to Filesystem Locations Apache HTTP Server Version 2.2
  7. ^ CGI Primer (Mirror at

External links

  • GNU cgicc, a C++ class library for writing CGI applications
  • CGI, a standard Perl module for CGI request parsing and HTML response generation
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.