Chapter 4: System Requirements

PHP uses a lot of the same environment variables as CGI, and a few special ones of its own. If a PHP program isn't behaving properly, it may be due to an environment variable that has a non-standard name - or isn't available. You can check this out by uploading and running a diagnostic script which will display the complete environment.

This script is very tiny, and here it is:

<?php phpinfo(); ?>

Note: The reason this script is so tiny is that all it has to do is to call a built-in function called phpinfo. PHP has a large number of these built-in functions. You can use them to do lots of common tasks without having to write any code of your own. That's a real time-saver, believe me!

Save this into a file and name it "phpinfo.php". Upload it to your server. Put it in the same folder with your web pages. Then run it by typing:

http://www.yourdomain.com/phpinfo.php

CGI-BIN access

First, the good news! PHP files will load and run in the same folder as your ordinary HTML files (web pages). Think about that for a second. It means very little work to get them running. Just load and go! They can contain both scripting and HTML and you don't usually need to set any file permissions.

The most common exception to this is when your script will be writing to log files. If your PHP script needs to write to any file, you'll have to give write permission to the file itself OR to the folder that contains the files. The required permissions will usually be 777. Chapter 5 explains how to do this. Note: Sometimes a file that you only read needs to be set for 777 permissions.

When your web server gets a request for a .php file, it goes through a series of steps like this: First, it looks for any scripting code. If it finds any, it runs the code and keeps looking through the file. Then it looks for any code that can be sent to the browser as HTML.

Finally, it looks for the closing HTML tag so it knows where the page ends. Ultimately, the output must contain valid HTML. This is what is sent to the browser and appears on the visitor's screen. Any number of things to control how the resulting page looks can be done in the scripting code.

This is how you make pages "dynamic." They don't have to look exactly the same each time they load. They can have forms, etc., that can make the page re-draw itself with new content when the "submit" button on the form is clicked. Database-driven pages that show exactly what the visitor requested are easy to make with PHP. A good example is a catalog page displayed after some kind of search.

So what's the big deal with the cgi-bin folder, then? OK, that's a fair question. The answers have to do mostly with security. As a general rule, files in the cgi-bin folder are not available for viewing in a browser.

So if your PHP scripts create log files that you don't want prying eyes to see, have the script access them in the cgi-bin folder. In other words, these log files should be created in, or uploaded to, the cgi-bin folder. Their file permissions should be set to be as restrictive as possible. Any .php files that you want well hidden from hackers can be placed in this folder.

When some "bad" person deliberately types in the path to a file you don't want anyone to see, they should get the 403 error "You are forbidden to access files in this folder."

Note: Be sure you test this! With some web server configurations, it can be possible to list and view files in the cgi-bin folder. If this is true on your server, fix it immediately. You may be able to do it yourself or you may need to get help from tech support. Either way, make sure it's fixed before you have any visitors to your site.

When you look at the features offered by a hosting company, they should proudly mention that they grant you "full CGI-BIN access", or say that "you get your own cgi-bin directory" or some other such wording. If they fail to mention it, odds are it's not available to you. This is a case where you need to check with tech support before you sign up for the hosting service.

There are two main issues here. First, can you put your script (s) in this directory? This is most often done with FTP. First you start your FTP client. Select the "local" directory (on your machine) that contains the script. Select the cgi-bin directory on the "remote" machine (your Web server). Then you transfer the file from your machine to the Web server.

Second, is this a secure operation? What I mean is this: If you must use a User ID and a password to get into your Web host's FTP server, your FTP access isn't "anonymous." That means that only you can view, upload, rename, delete the files in your cgi-bin directory. That's the way you want it to be.

Copyright © 2004 Steve Humphrey