The Common Gateway Interface (CGI) is a standard or protocol for external "gateway" programs to interact with information servers such as those running the web's HTTP protocol. The CGI standard can be used in other information systems as well, but to the extent that the web is the highly dominant and most visible of all such systems, CGI may be thought of as a protocol almost exclusively found on the web.
An HTML document downloaded from the webserver and displayed on the client is static--it does not change with time, and it also cannot accept the user's input to carry out special tasks (such as accepting a query for a web search). The HTML document is a mere text file whose character and content do not change with time. A CGI program, on the other hand, is a mini-application that is executed on the webserver in real time while the user is visiting the web page from which it is called. A CGI program is thus dynamic, and can accept user input and output specific information specifically requested by the user, or can carry out computations requested by the user, and so on.
A CGI application would traditionally be described as a script, rather than as a true program. The distinction is to a certain extent semantic--a "script" is thought to be any application that is created merely by the line-by-line interpretation of code in some functional programming language like Perl or Python. A "program" in the classical sense is, on the other hand, code written in a language such as C or C++ which has to be compiled to obtain a binary (executable) that is then run; the program itself cannot be run on any system. CGI is most commonly implemented by using scripts in a language such as Perl; thus it is accurate to call a CGI application as a script rather than a program, though the distinction is sometimes obscured.
CGI is used on the web most commonly when "web forms" are needed for accepting user input. Such forms are commonly used for such purposes as sending mail to a maintainer of a website with comments, or for submitting a query to an online dictionary, search engine, or other such service.
Use of CGI is the classical, less-refined solution to the kinds of problems that CGI was meant to solve--more recent approaches have tended to favor other solutions--most importantly, the use of server-side Java (servlets). However, we should observe that contrary to a lot of confused thinking that prevails, CGI and Java are not fundamentally alike or compatible. Java is mostly used for client-side programming, although it has a special API that allows for creation of servlets. CGI is never used for client-side programming--it is, as noted, a protocol for interaction with an information server (most commonly a webserver). It is possible for client-side Java and server CGI to be combined into one seamless user application--for instance, it is possible to create a Java applet that will display a map or other region of interest to enable a user's input; when the user picks a region on the map, or otherwise makes an input, CGI can be used to have the server process it and return a suitable output back to the client side.
Another option that is in some ways a competitor to CGI is server-side includes (SSI). The basic SSI is a simple interface for basic dynamic content--for example, such a one can be applied to insert a date and time (such as time of last modification) into a web page. No user input can be accepted and processed. Enhanced SSI is able to handle more complex tasks though it does not have the full functionality offered by a CGI or by server-side Java.
Enhanced CGI-like protocols exist which perform the same function as CGI itself, but have the advantage that they typically use less server resources (memory, CPU cycles, etc.) than standard CGI--efficiency is, as may be guessed, a chief concern for major webservers that may receive thousands or more visitors per day, and for servers such as those hosting search engines, which need to do a fair amount of dynamic processing rather than just delivering static content upon demand.
CGI applications are installed by writing a suitable script in Perl or some other supported functional language, and by then making it available from a suitable location on the webserver's directory (usually called a "cgi-bin" directory or something similar). If the permissions are set correctly so that the file placed in the CGI directory can be accessed (read and executed), then it can be invoked from web pages hosted by the server.
Unfortunately, as with most other things on the web, or even on the Internet as a whole, CGI applications tend to be sources of security concerns. The basic CGI protocol itself is not believed to have any serious holes or flaws in it, but it does allow for the creation of scripts that are not up to snuff, security-wise. CGI applications should be created and used with as much care as any programs, but a large number of scripts that are insecure exist, for which reason many web administrators do not allow users to install and use arbitrary CGI scripts.
This is the complete article, containing 873 words
(approx. 3 pages at 300 words per page).
