 |
|
|
|
 |
||
|
||
|
|
|
|
CGI Troubleshooting Tipsby Brent MichalskiJuly 31, 1998 We have been through several articles so far but we really haven't covered how Common Gateway Interface (CGI) programs work, what CGI really means, or what to do when you encounter errors in your programs. In this article, I want to digress a bit and hopefully answer these questions. While you may be able to write great CGI programs, if you can't get them working on your server, they won't do you much good. Therefore, being able to troubleshoot your CGI programs is just as important as writing them. If you know a little about what is happening underneath it all and a little bit about troubleshooting, it can help you out more than you can imagine. What is CGI?CGI is a way for your Web programs to communicate with the user's browser. CGI programs can be written in just about any language that runs on a Web server, including C, C++, Visual Basic or even shell scripts. But, the majority of CGI programs are written in Perl. When someone says they are a CGI programmer, it doesn't mean they program in CGI, it simply means they can write CGI programs in whatever language they choose.In addition to interacting with the Web browser, CGI programs can be
used to interact with other applications by configuring the MIME-types
(described below). For example, your CGI programs can be set up to work
in conjunction with Microsoft Word, thus extending the power and capabilites
of your CGI programs.
MIME typesOk, just so there isn't any confusion, MIME types are not those highly annoying people who wear make-up and do impressions in the park. MIME types were originally designed for handling Internet mail. MIME actually stands for Multipart Internet Mail Extensions. MIME types can be used to tell the hypertext transport protocol (HTTP, your Web server), what type of data is being sent. Because MIME types must follow strict guidelines, they are also a common source of errors when CGI programming.First and foremost, the MIME type must be the very first line printed by your CGI program. The MIME type looks something like this: Content-type type/subtype <line feed> <line feed>The Perl code looks like this: print "Content-type: text/html\n\n";Remember, this must be the first line of your CGI program. If you try to print something out before this line, you will get a "Server Error." To learn all the juicy details about MIME types, please visit: http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html. Environment Variables
Environment variables are a standard set of varaibles that you can use to get information about the server and client environments. There are quite a few environment variables available to your CGI program, but I think the most important one is the QUERY_STRING variable. In Perl, when you want to get the value of an environment variable, you simply need to do the following: $query_string = $ENV{QUERY_STRING};
And you have set the value of $query_string to the value that was
passed by the server.
Here is a quick-n-dirty example that prints out the environment variables for you to see. Notice that instead of creating a new variable to store each environment variable (like in the example above), I used the actual environment variable. I figured that since it is already stored in a variable, why waste the memory for this short example. print "Content-type: text/html\n\n";
print<<HTML;
<HTML><HEAD><TITLE>Environment Variables</TITLE></HEAD>
<BODY BGCOLOR="#FFFFFF">
<CENTER>
<FONT FACE=ARIAL SIZE=6>Environment Variables</FONT>
<HR WIDTH=85%>
</CENTER><P>
<PRE>
HTML
print "SERVER_SOFTWARE = $ENV{SERVER_SOFTWARE}\n";
print "SERVER_NAME = $ENV{SERVER_NAME}\n";
print "SERVER_PROTOCOL = $ENV{SERVER_PROTOCOL}\n";
print "SERVER_PORT = $ENV{SERVER_PORT}\n";
print "GATEWAY_INTERFACE = $ENV{GATEWAY_INTERFACE}\n";
print "REQUEST_METHOD = $ENV{REQUEST_METHOD}\n";
print "HTTP_ACCEPT = $ENV{HTTP_ACCEPT}\n";
print "PATH_INFO = $ENV{PATH_INFO}\n";
print "PATH_TRANSLATED = $ENV{PATH_TRANSLATED}\n";
print "SCRIPT_NAME = $ENV{SCRIPT_NAME}\n";
print "REMOTE_HOST = $ENV{REMOTE_HOST}\n";
print "REMOTE_ADDR = $ENV{REMOTE_ADDR}\n";
print "REMOTE_USER = $ENV{REMOTE_USER}\n";
print "CONTENT_TYPE = $ENV{CONTENT_TYPE}\n";
print "CONTENT_LENGTH = $ENV{CONTENT_LENGTH}\n";
print "QUERY_STRING = $ENV{QUERY_STRING}\n";
print "<BODY></HTML>";
There is also a text file
containing this code.
I like to use the query_string variable in many of my programs. Examine the URL of the link to the example above. It includes a ? followed by some text. By using this method, you can pass variables to your programs from your URL. I often use this to tell my CGI programs what they need to do. For example: http://www.something.com/cgi-bin/myprog.cgi?configure passes a QUERY_STRING value of configure to the program, perhaps telling it to run the configuration subroutine. By being aware of the environment variables available to you, you can utilize them whenever necessary to make your CGI programs even more powerful. A complete list of CGI environment variables can be found here. Troubleshooting Your CGI ProgramsSo you have your CGI program written and on the server but you keep getting "Internal Server Error" or similar error messages. What do you do?While I can't possibly give you the answers to all possible problems, I can give you some tips that will help you to troubleshoot common errors in CGI programs. Most of these tips are biased towards scripts running on Unix servers. If your server is a Windows, Macintosh or other system, you may still find some valuable information here, and may be able to adopt it to your particular system.
chmod 755 programname This command will make your program executable. If you don't have access
to a command line, some newer FTP programs allow you to make a unix program
executable.
Personally, I think the best tool for troubleshooting CGI programs is the command line. You now know what the MIME header looks like, make sure that it is the first line printed on the command line output and the rest of the output should be from the rest of your program. If you have a proper MIME type printing first, followed by what looks like valid output when you run from the command line, and you are sure that you have the permissions configured properly, there is no reason that you shouldn't get some sort of output when you run the program via the Web. After the command line, or if you don't have access to a command line prompt, the next most useful place to search for errors is the Web server error log files. Any errors produced by the program, including errors identifying incomplete headers (the MIME type problem) will be sent to the server's error log. Many Web hosting services don't provide access to the command line, but will provide access to the error logs. Wrapping it upThis week I have presented some material that will make your CGI programming life easier. There are many different things to remember when writing CGI programs, so these basic details should help you out quite a bit.If you still run into problems, here are links to the Web pages that I visit daily covering Perl and CGI, and a list of the important newsgroups. I consider these resources more valuable than any other programming resources that I own because there is such a wealth of information! Chances are that when you encounter a problem, fifty other people have had the same problem before and the answer is available somewhere online. I always start at: www.perl.com If I can't find the answer in the resources there, I check the newsgroup archives at: www.dejanews.com Here are the rest of the great links:
The Perl newsgroups are:
Next week we will be getting back into the programs. See you then!
|
|
|
|
|
Web Techniques and Web Design and Development copyright © 1995-99 Miller Freeman, Inc. ALL RIGHTS RESERVED |
|
