Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

•  REMOTE_IDENT—If the server and client support RFC 931, this variable will contain the identification information supplied by the remote user’s computer. Very few servers and clients still support this protocol, and the information is almost worthless because the user can set the information to be anything he wants. Don’t use this variable even if it’s supported by your server.

•  REMOTE_USER—If AUTH_TYPE is set, this variable will contain the user name provided by the user and validated by the server. Note that AUTH_TYPE and REMOTE_USER are only set after a user has successfully authenticated (usually via a username and password) his identity to the server. Hence, these variables are useful only when restricted areas have been established and then only in those areas.

•  REQUEST_METHOD—Supplies the method by which the script was invoked. Only GET and POST are meaningful for scripts using the HTTP/1.0 protocol.

•  SCRIPT_NAME—This is the name of the script file being invoked. It’s useful for self-referencing scripts. For example, scripts use this information to generate the proper URL for a script that gets invoked using GET, only to turn around and output a form that, when submitted, will reinvoke the same script using POST. By using this variable instead of hard-coding your script’s name or location, you make maintenance much easier; for example, /cgi-bin/myscript.exe.

•  SERVER_NAME—Your Web server’s host name, alias, or IP address. It’s reliable for use in generating URLs that refer to your server at runtime; for example, www.yourcompany.com.

•  SERVER_PORT—The port number for this connection; for example, 80.

•  SERVER_PROTOCOL—The name/version of the protocol used by this request; for example, HTTP/1.0.

•  SERVER_SOFTWARE—The name/version of the HTTP server that launched your script, for example, HTTPS/1.1.

CGI Script Portability

CGI programmers face two portability issues: platform independence and server independence. Platform independence is the capability of the code to run without modification on a hardware platform or operating system different from the one for which it was written. Server independence is the capability of the code to run without modification on another server using the same operating system.

Platform Independence

The best way to keep your CGI script portable is to use a commonly available language and avoid platform-specific code. It sounds simple, right? In practice, this means using either C or Perl and not doing anything much beyond formatting text and outputting graphics.

Does this leave Visual Basic, AppleScript, and UNIX shell scripts out in the cold? Yes, I’m afraid so, for now. However, platform independence isn’t the only criterion to consider when selecting a CGI platform. The speed of coding, the ease of maintenance, and the capability to perform the chosen task should also be considered.

Certain types of operations simply aren’t portable. If you develop for 16-bit Windows, for instance, you’ll have great difficulty finding equivalents on other platforms for the VBX and DLL functions you use. If you develop for 32-bit Windows NT, you’ll find that all your asynchronous Winsock calls are meaningless in a UNIX environment. If your shell script does a system() call to launch grep and pipe the output back to your program, you’ll find nothing remotely similar in the Windows NT environment, unless you add an NT version of grep to the system. And AppleScript is good only on Macintoshes.

If one of your mandates is the capability to move code among platforms with a minimum of modification, you’ll probably have the best success with C. Write your code using the standard functions from the ANSI C libraries and avoid making other operating system calls. Unfortunately, following this rule will limit your scripts to very basic functionality. If you wrap your platform-dependent code in self-contained routines, however, you minimize the work needed to port from one platform to the next. As you saw in the section “Planning Your Script,” when talking about encapsulation, a properly designed program can have any module replaced in its entirety without affecting the rest of the program. Using these guidelines, you may have to replace a subroutine or two, and you’ll certainly have to recompile; however, your program will be portable.

Perl scripts are easier to maintain than C programs, mainly because no compile step is used. You can change the program quickly when you figure out what needs to be changed. And there’s the rub: Although learning to write simple Perl is easier than learning C for many people, Perl has many obscure subtleties, and the libraries tend to be much less uniform—even between versions on the same platform—than do C libraries. You pay for all that wonderful string-processing and pattern-handling power. Also, Perl for Windows NT is fairly new and still quirky, although the most recent versions are much more stable. And in fairness to Perl, Win32 is not the only compiler or interpreter to be quirky on a relatively new operating system such as NT 4.0 and now 5.0.

Server Independence

Far more important than platform independence is server independence. Server independence is fairly easy to achieve, but for some reason, it seems to be a stumbling block to beginning script writers. To be server independent, your script must run without modification on any server using the same operating system. Only server-independent programs can be useful as shareware or freeware, and without a doubt, server independence is a requirement for commercial software.

Most programmers think of obvious issues, such as not assuming that the server has a static IP address. The following are some other rules of server independence that, although obvious once stated, nevertheless get overlooked time and time again: