Common Gateway Interface

From Wikipedia, the free encyclopedia

The Common Gateway Interface (CGI) is a standard protocol for interfacing external application software with an information server, commonly a web server.

The task of such an information server is to respond to requests (in the case of web servers, requests from client web browsers) by returning output. Each time a request is received, the server analyzes what the request asks for, and returns the appropriate output. The two simplest ways, for the server, of doing this are the following:

• if the request identifies a file stored on disk, return the contents of that file;
• if the request identifies an executable command and possibly arguments, run the command and return its output

CGI defines a standard way of doing the second. It defines how information about the server and the request is passed to the command in the form of arguments and environment variables, and how the command can pass back extra information about the output (such as the type) in the form of headers.

Contents 1 cgi-bin 2 History 3 Example 4 Implementation 5 Alternatives 6 References 7 See also 8 External links

[edit] cgi-bin

Web servers often have a cgi-bin directory at the base of the directory tree to hold executable files called with CGI.

[edit] History

In 1995, the World Wide Web (WWW) was small but booming. WWW software developers and web site developers kept in touch on the www-talk mailing list, so it was there that a standard for calling command line executables was agreed upon. Specifically mentioned in the CGI spec are the following contributors:

• Rob McCool (author of the NCSA httpd web server)
• John Franks (author of the GN web server)
• Ari Luotonen (then developer of the CERN httpd web server)
• Tony Sanders (author of the Plexus web server)
• George Phillips (web server maintainer at the University of British Columbia)

Rob McCool drafted the initial specification, and NCSA still hosts it. It was swiftly implemented in all servers.

[edit] Example

An example of a CGI program is the one implementing a wiki. The user agent requests the name of an entry; the server will retrieve the source of that entry's page (if one exists), transform it into HTML, and send the result back to the browser or prompt the user to create it. All wiki operations are managed by this one program.

[edit] Implementation

The way CGI works from the Web server's point of view is that certain locations (e.g. http://www.example.com/wiki.cgi) are defined to be served by a CGI program. Whenever a request to a matching URL is received, the corresponding program is called, with any data that the client sent as input. Output from the program is collected by the Web server, augmented with appropriate headers as defined by the CGI spec, and sent back to the client, routed to logs or email as appropriate.

This is a low-tech approach. Calling a command generally means the invocation of a newly created process. Starting up the process will usually take up 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 program is called often, the workload can quickly overwhelm web servers.

[edit] Alternatives

Several approaches can be adopted for remedying this:

• FastCGI is a CGI script accelerator. It brings execution within the web server while retaining the CGI calling conventions.
• The popular Web servers developed their own extension mechanisms that allows third-party software to run inside the web server itself, e.g. Apache modules, Netscape NSAPI plug-ins, IIS ISAPI plug-ins. While these interfaces didn't reach the same standardization achieved for CGI, they were at least published and at least partly implemented on multiple web servers.
• Another approach is to ensure that command invocation doesn't actually start up a new process each time; e.g. RPG programs on the IBM iSeries/AS400 may stay resident in memory with databases already open, allowing for faster execution on subsequent usage.

The optimal configuration for any web application will obviously depend 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 budget.

[edit] References

• Common Gateway Interface: Introduction. Retrieved February 4, 2008.

[edit] See also

• FastCGI
• QDecoder
• SCGI
• Application server

[edit] External links

• The CGI standard at w3.org.
• The CGI/1.1 specification.
• The complete list of CGI variables is at [1].
• The SCGI protocol is a replacement for the Common Gateway Interface (CGI) protocol.
• Python CGI Tutorial - shared host setup, forms, debug, shell commands, cookies, etc.
• Python CGI Scripts - A set of CGI applications and modules for CGI programming with the Python language.
• Ovid's (Perl) CGI tutorial [retrieved via The Internet Archive]

v • d • e Web server interfaces General Common Gateway Interface (CGI) · Simple CGI · FastCGI Technology specific ISAPI · Java Servlet · NSAPI · AJP · Python WSGI Apache modules mod_perl · mod_php · mod_python (mod_wsgi) · mod_ruby

v • d • e Standards of the World Wide Web Consortium Recommendations Canonical XML · CDF · CGI · CSS · DOM · HTML · MathML · OWL · PLS · RDF · RDF Schema · SISR · SMIL · SOAP · SRGS · SSML · SVG · SPARQL · Timed Text · VoiceXML · WSDL · XForms · XHTML · XML · XML Base · XML Events · XML Information Set · XML Schema (W3C) · XML Signature · XPath · XPointer · XQuery · XSL Transformations · XSL-FO · XSL · XLink Notes XHTML+SMIL · XAdES Working Drafts CCXML · CURIE · InkML · XFrames · XFDL · WICD  · XHTML+MathML+SVG · XBL · HTML 5