Common Gateway Interface: Difference between revisions
I disagree with this edit for two reasons: (1) the modification no longer explains the name CGI script" (2) the new text is highly misleading for various reasons. please Talk |
CGI's can be written in any language, not only scripting languages. Stating scripting languages leads to misunderstandings. |
||
| Line 1: | Line 1: | ||
The '''Common Gateway Interface''' ('''CGI''') is a [[Standardization|standard]] [[Protocol (computing)|protocol]] that defines how [[webserver]] software can delegate the generation of [[webpage]]s to a [[console application]]. |
The '''Common Gateway Interface''' ('''CGI''') is a [[Standardization|standard]] [[Protocol (computing)|protocol]] that defines how [[webserver]] software can delegate the generation of [[webpage]]s to a [[console application]]. Such applications can be written in any programming language. |
||
Such applications are known as ''CGI script''s - they are usually written in a [[scripting language]]. |
|||
==Purpose== |
==Purpose== |
||
Revision as of 21:29, 6 January 2010
The Common Gateway Interface (CGI) is a standard protocol that defines how webserver software can delegate the generation of webpages to a console application. Such applications can be written in any programming language.
Purpose
The task of a webserver is to respond to requests for webpages issued by clients (usually web browsers) by analyzing the content of the request (which is mostly in its URL), determining an appropriate document to send in response, and returning it to the client.
If the request identifies a file on disk, the server can just return the file's contents. Alternatively, the document's content can be composed on the fly. One way of doing this is to let a console application compute the document's contents, and tell the web server to use that console application. CGI specifies which information is communicated between the webserver and such a console application, and how.
The webserver software will invoke the console application as a command. CGI defines how information about the request (such as the URL) is passed to the command in the form of arguments and environment variables. The application is supposed to write the output document to standard output; CGI defines how it can pass back extra information about the output (such as the MIME type, which defines the type of document being returned) by prepending it with headers.
History
In 1993, 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 RFC 3875[1] are the following contributors:
- Rob McCool (author of the NCSA httpd web server)
- John Franks (author of the GN web server)
- Ari Luotonen (the 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)
The NCSA team wrote the specification,[2] and NCSA still hosts it at its original location. [3][4] The other webserver developers adopted it, and it has been a standard for webservers ever since.
Example
An example of a CGI program is 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.
More details
From the Web server's point of view, certain locators, e.g. http://www.example.com/wiki.cgi, are defined as corresponding to a program to execute via CGI. When a request for the URL is received, the corresponding program is executed.
Data is passed into the program using environment variables. This is in contrast to typical execution, where Command-line arguments are used. In the case of HTTP PUT or POSTs, the user-submitted data is provided to the program via the standard input.[5]
Web servers often have a cgi-bin/ directory at the base of their directory tree to hold executable files called with CGI.
The program returns the result to the web server in the form of standard output, prefixed by a header and a blank line.
Header format
The header is encoded in the same way as an HTTP header and must include the MIME type of the document returned.[6] The headers are generally forwarded with the response back to the user, supplemented by the web server.
Drawbacks
In the case that a CGI call involves use of a scripting language such as csh or perl, coding errors are highly likely to result in a code injection vulnerability.
Calling a command generally means the invocation of a newly created process. Starting up the process can 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 command is called often, the resulting workload can quickly overwhelm the web 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 scripting languages. The overhead involved in process creation can be reduced by solutions such as FastCGI, or by running the application code entirely within the webserver using special extension modules.
Alternatives
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, 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.
- 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 much of the overhead CGI incurs by 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.
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.