Once upon a time, the World Wide Web was a relatively static place. The Web server's sole function was to simply deliver a requested Web page, written in HTML, to a client browser. Over time, developers started looking for ways to . . .
Once upon a time, the World Wide Web was a relatively static place. The Web server's sole function was to simply deliver a requested Web page, written in HTML, to a client browser. Over time, developers started looking for ways to interact with users by providing dynamic content -- that is, content that displayed a form or executed a script based on user input. Thus Server Side Includes (SSI) and the Common Gateway Interface (CGI) were born.

A Server Side Include page is typically an HTML page with embedded command(s) that are executed by the Web server. An SSI page is parsed by the server (a "normal" Web page is not), and if SSI commands are found they are executed before the resultant output is delivered to the requesting client. SSI is used in situations that demand a small amount of dynamic content be inserted in a page, such as a copyright notice or the date. SSI can also be used to call a CGI script; however, there is a performance penalty associated with SSI. The server must parse every page designated as SSI-enabled, which is not an optimal solution on a heavily loaded Web server.

The CGI is a standard for communication between a program or script, written in any one of several languages, and a Web server. The CGI specification is very simple: input from a client is passed to the program or script on STDIN (standard input). The program then takes that information, processes it, and returns the result on STDOUT (standard output) to the Web server. The Web server combines this output with the requested page and returns it to the client as HTML. CGI applications do not force the server to parse every requested page; only pages containing CGI-recognized arguments involve further processing.

The link for this article located at IBM is no longer available.