CGI
From DocForge
The Common Gateway Interface (CGI) is a standard protocol for interfacing client applications with a dynamic information server application, typically a web server. This allows the server to pass requests from a web browser to an external application. The web server can then return the output from the application to the web browser.
Contents |
[edit] Implementation
The way CGI works from a web server's point of view is that certain URLs 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, and sent back to the client.
The simplest implementation of CGI generally requires a fresh copy of the program to be executed for every CGI request. The workload could quickly overwhelm web servers, inspiring more efficient technologies such as mod_perl or PHP that allow script interpreters to be integrated directly into web servers as modules. This avoids the overhead of repeatedly loading and initializing language interpreters. However, this is only applicable for high-level languages that need interpreters. Such overloads can be avoided by utilizing languages like C. By using C or similar compiled languages it is possible to reach higher efficiency levels, because such programs can terminate their execution cycle faster than interpreted languages with less operating system overhead. Even better, 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. A software engineer analyzes these trade-offs to determine the best implementation for a given task and budget.
Web servers often have a cgi-bin directory at the base of the domain, to hold executable files.
[edit] Workarounds for Scripting Languages
The overhead of spawning new processes to compile the server code can be easily handled if the code is only changed occasionally. One example is FastCGI, while others include programming accelerators that take a web script when initially called and store a compiled version of the script in a system location so that further requests for the file are automatically directed to the compiled code instead of invoking the script interpreter every time the script is called. When scripts are changed, the temporary accelerator cache can be emptied to ensure that the new script is called instead of the old one.
Thus for languages such as C, Pascal, or RPG, which are usually compiled anyway, CGI programs are no different from other programs in this regard, and require no special processing.
Another approach used for scripting languages is to embed the interpreter directly into the web server so that it can be executed without creating a new process. Modern web servers like Apache or Cherokee have a number of modules for Perl, PHP, Python and Ruby which do this.
[edit] References
[edit] See Also
- C programming language
- FastCGI
- Perl
- QDecoder
- Web application
[edit] External Links
- The CGI standard at w3.org.
- The CGI/1.1 specification.
- The complete list of CGI variables is at http://hoohoo.ncsa.uiuc.edu/cgi/env.html.
- 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

