CGI and PHP Server Pages Overview

only for RuBoard - do not distribute or recompile

To understand how IMP works, you need a brief explanation of CGI and modules. You need to know how CGI technology works and how it differs from the method used for the IMP project.

NOTE

I have often had people who proclaimed they "know more than you" tell me CGI is the only way to go. They have even offered to "fix" my system for me. Don't let some so-called expert do this to you! With the information covered in this section, you will know why CGI should not be used for this project.

CGI was the first method widely used by Web servers to execute user -provided programs triggered by their Web pages. This method is still available. If you know about this method, you might wonder why IMP uses PHP as a module.

How CGI Works

Common Gateway Interface is abbreviated CGI. A CGI script is any program that is run by a Web server when requested by a Web browser. These programs typically run in memory separated from the Web browser. They get information the user put into a Web page through environment variables , or through stdin. (See the explanation of stdin and stdout in Chapter 6, "IMP.")

When CGI scripts use the GET request method for getting data, the data is passed on the URL line and is reflected in the environment variables. This data is visible to the Web browser user. You should not use this method for sensitive data. An example of using the CGI GET method can be found using search engines. Here is a sample search on a fictional search engine:

 http://www.mm.com/Mamma?lang=1&timeout=4&qtype=0&query=cgi+script

The ? symbol starts the information to be given to the CGI script. The & character indicates that a new variable is beginning. The = sign assigns a value to a variable name. The variable name is on the left of the =, and the value is on the right. Any space characters in the text are replaced with the + sign. The receiving script must parse this information to use it.

When CGI scripts use the POST method, the information is sent to stdin using the same format as described for the GET method. The environment variable REQUEST_METHOD is set to the string POST for POST methods , GET for GET methods. Data sent on stdin is not visible to the user of the Web browser. That data can be derived from the Web page the user filled out, or it can be based on computation. The only advantage here is that a casual over-the-shoulder observer might not easily determine what information was sent to the server. Security-wise, both POST and GET are about the same.

CGI scripts are typically much slower than PHP. The slowness comes from the time necessary to allocate system resources, such as memory, and execute the program. The program often must be loaded from disk, which incurs greater time penalties. For small scripts, PHP running as a module is much faster.

You can run PHP as a CGI script if you want. However, to get the best performance from your Web mail program, you do not want to do this. In this project, you will be installing PHP as a module.

How PHP Works in the ESL Mode

ESL stands for Embedded Scripting Language. When PHP is run in this mode a CGI script is not called. Instead, the server is given clues through configuration files that the Web page can contain PHP code. When the tags <? and ?> are seen, the server runs the page through the PHP engine before delivering the page to the Web browser.

By running PHP as a module, you cut out a lot of time the user would normally have to wait in the CGI mode. The PHP module is resident in memory, as opposed to being loaded from the hard drive for each use. To achieve the most responsiveness, you never want to use PHP as a CGI script engine.

NOTE

To work with Front Page and some XML parsers, you should change the initial tag to read <?php. This is not an issue if you won't be editing with Front Page or using an XML parser.

To avoid calling PHP as a CGI script, it must be installed as a module in your Web server. The configuration file changes you made tell the Web server that PHP is a module. The next step is to install PHP.

NOTE

This book covers the free Apache Web server for this project. It must be noted that other Web servers support PHP as a module also. One that comes to mind is the Xitami Web server.

Testing the PHP and IMP Configuration

Red Hat 6.1 has a bug with the PHP RPM file included on its install CD-ROM. Therefore, you must do an install of PHP following the instructions in Chapter 5, "PHP3," before you can test.

After you have installed PHP per the directions in Chapter 5, you can try a simple test. Create a directory named test under /home/httpd/html. In this create a simple Web page with the name index.php3. The contents of the Web page will be as follows :

 <?php phpinfo() ?>

Then, run Netscape or Internet Explorer, and enter the following URL:

 http://lin/test/index.php3

Or, if you are running X Windows on the Linux machine, enter the following:

 http://127.0.0.1/test/index.php3

You should see a Web page similar to Figure 4.1. This figure shows a stripped-down PHP that does not include any of the services we will need. Yours will be different.

Figure 4.1. The standard PHP with no added features.

If you do not see this Web page, verify your httpd daemon is running. If it is running, revisit the edits in the httpd.conf file and check your error messages in /var/log/messages, /var/log/secure, /var/log/httpd/error_log, and /var/log/httpd/access_log. In most cases, the information there will tell you what you have done wrong. In some circumstances this will not occur.

only for RuBoard - do not distribute or recompile