HistoryIn 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 drafted the initial specification, and NCSA still hosts it. It was swiftly implemented in all servers. ExampleAn 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 (usually) program. This would require a server to be present and operating for one to use a wiki on one's own local machine, addressed as 'localhost'. ImplementationFrom 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[1]. Web servers often have a cgi-bin directory at the base of the 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 formatThe header is encoded in the same way as a HTTP header and must include the MIME type of the document returned[2]. The headers are generally forwarded with the response back to the user, supplemented by the web server. DrawbacksThis is a low-tech approach. 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 program is called often, the workload can quickly overwhelm web servers. AlternativesSeveral approaches can be adopted for remedying this:
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. References
See also
External links
| | |||||||||||||||||