14.1 Common Gateway Interface (CGI)

14.1 Common Gateway Interface (CGI)

14.1.1 What is CGI?

There is no doubt that World Wide Web browsers such as IE and NS are important for the entire Internet. They are among the most important software to link information and people around the world and conquer every corner of the Internet. Nowadays, the functionalities of browsers are far beyond the original design to display documents written in the HTML/XHTML language. At a minimum level we can expect a capable browser to carry out the following:

• Display documents written in the XHTML language.

• Understand CSS styles.

• Execute scripts such as ECMAScript and others.

• Implement the DOM so that events and style can be controlled using standard scripts.

Even all these functionalities cover only half of the picture, i.e., client-side activities. A basic capable browser should also act as an interface for the following server-side activities:

• Execute server programs.

• Accept server technologies such as Perl, ASP, and PHP.

• Communicate with databases in remote sites.

• Safeguard the network and perform security encryption and business transactions.

In order to perform these tasks, processing power on the server side is needed. Server technologies open a new chapter for Web applications.

As a simple example, if you have an executable program such as myprogram (or myprogram.exe for Microsoft systems) on the root directory of the server www.pwt-ex.com, you can run this program by issuing the following http:// command in the address bar of the browser:

http://www.pwt-ex.com/myprogram

If the executable program generates an XHTML document to the calling browser via the standard input/output (I/O) channel, the browser can process and display the document. The entire process is generally regarded as the Common Gateway Interface (CGI) process.

In particular, a script or executable program is considered as a CGI script or program if

• it is inside and executable by the server;

• the execution is triggered by the browser;

• the result can be displayed on the browser window.

Based on this specification, CGI scripts and programs can be written in many languages such as Perl, ASP, PHP, and C/C++.

You already have some experience on Perl, ASP, and PHP from Chapters 12 and 13. In this chapter you will learn CGI technologies from a global point of view. We begin by executing a simple C/C++ program using the CGI process. From CGI's point of view, all ASP, PHP, and Perl can be considered as a preprocessor to produce XHTML documents. Even server software such as Apache and/or IIS can be considered as a special CGI application.

One of the central ideas of this book is to keep language features and new commands to a minimum and concentrate on applications on the Web. For each technology or language such as Perl, ASP, and PHP, a natural yet minimal approach is introduced. We will not provide a comprehensive discussion of all aspects of the language features. Alternatively, an easy to understand technological background is provided. Our main objective is to show how to apply technology to various applications and to direct them into action. This chapter provides fundamental knowledge on CGI and is a solid base for a more advanced study of server technologies and the chapters to come. Now it's time to consider the structure of the CGI.

14.1.2 The structure of CGI: how does it work?

Apart from requesting an XHTML document, the HTTP, generally, can also identify a file that contains a program or script. Depending on the settings of the server, the program may be executed when a user activates the link containing the URL. This is the CGI process. To understand how it works, you need to consider the structure and actual dialog (canonical interaction) between the browser and server.

Figure 14.1 shows a CGI application in action and the necessary calling procedure. In the figure, there is one Web client and two HTTP servers.

The Web client computer requests an XHTML document from server A and displays it on the screen. Suppose this document has a hyperlink to a program "myprogram" on server B. This program is run if the link is activated. The link can be any ordinary HTTP connection available. When the program is called, a special request is sent to server B. The message is like this:

Listing: ex14-01.txt - CGI Request Message To Server

 1:  GET /myprogram HTTP/1.0
 2:  Accept: www/source
 3:  Accept: text/html
 4:  Accept: image/gif
 5:  Accept: image/jpg
 6:  User Agent: xxxx
 7:  From: xxxxxx
 8:    *** a blank line ***

This request causes the server to locate and execute the program myprogram. In order to display the result via the calling browser, the program usually generates a special message through server B back to the browser. For an HTTP network such as the Internet, the response message looks like the following:

Listing: ex14-02.txt - CGI Response From Server

1: HTTP/1.0 200 OK
2: Server: xxx xx
3: MIME-Version: 1.0
4: Content-type: text/html
5:  *** blank line ***
6: <html><title><head> ***</head></title>
7:  *** *** ***

The CGI request and response are similar to the canonical clientserver interaction discussed in Chapter 1. In fact, they are the standard CGI clientserver interaction.

The dialog illustrates two important points:

• The first five lines specify the CGI header needed for the CGI process.

• The remaining dialog (starting from line 6) contains the document displayable by the browser.

Any program or application generating the first five lines of ex14-02.txt and returning an XHTML document generally qualifies as a CGI application. The document will appear on the client (or browser) screen. This idea is the origin of almost all server technologies on the Web, including Perl, ASP, and PHP.

Let's consider some CGI applications in the next section.