A guide to CGI Scipts at 4eIT.com - Linux web hosting, complete web site solutions

Domain Name Registration
Linux Web Hosting
Web Hosting Reseller
Free Web Hosting

Frequently Asked Questions

CGI - Primary knowledge

?: What is CGI ?
$. The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers such as HTTP servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information. Here is a excellent description:
Common Assures you that CGI can be used by many languages and interact with many different types of systems. It doesn't tie you down to one way of doing what you want.
Gateway Suggests that CGI's strength lies not in what it does by itself, but in the potential access it it offers to other systems such as databases and graphic generators.
Interface    Simply means that CGI provides a well-defined way to call up its features-- in other words, that you can write programs that use it.

?: Should I use CGI or JAVA?
$. CGI and JAVA are fundamentally different, and for most applications are NOT interchangeable. CGI is a protocol for running programs on a WWW server. Whilst JAVA can also be used for that, and even has a standardised API (the servlet, which is indeed an alternative to CGI), the major role of JAVA on the Web is for client side programming (the applet). In certain instances the two may be combined in a single application: for example a JAVA applet to define a region of interest from a geographical map, together with a CGI script to process a query for the area defined. The concept of JAVA is totally different from that of CGI. CGI refers to server-side execution, while JAVA refers to client-side execution. There are certain things (like animation) which can be improved by using Java. However, you can continue to use Perl to develop server-side applications.

?: Should I use CGI or SSI or ... { PHP/ASP/... }
$. CGI and SSI (Server-Side Includes) are often interchangeable, and it may be no more than a matter of personal preference. Here are a few guidelines:
1. CGI is a common standard agreed and supported by all major HTTPDs. SSI is NOT a common standard, but an innovation of NCSA's HTTPD which has been widely adopted in later servers. CGI has the greatest portability, if this is an issue.
2. If your requirement is sufficiently simple that it can be done by SSI without invoking an exec, then SSI will probably be more efficient. A typical application would be to include site wide 'house styles', such as toolbars, netscapeised <body> tags or embedded CSS style sheets
3. For more complex applications - like processing a form -where you need to exec (run) a program in any case, CGI is usually the best choice.
4. If your transaction returns a response that is not an HTML page, SSI is not an option at all. Many more recent variants on the theme of SSI are now available. Probably the best-known are PHP which embeds server-side scripting in a pre-html page, and ASP which is Microsoft's version of a similar interface.

?: Should I use CGI or an API?
$. APIs are proprietary programming interfaces supported by particular platforms. By using an API, you lose all portability. If you know your application will only ever run on one platform (OS and HTTPD), and it has a suitable API, go ahead and use it. Otherwise it is advisable to use CGI.

?: Do I need to be on Unix/ Linux?
$. No, but it helps. The Web, along with the Internet itself, C, Perl, and almost every other Good Thing in the last 20 years of computing, originated in Unix. Linux originated from UNIX and so the same goes for it.

?: Do I have to use Perl?
A. No - you can use any programming language you please. Perl is simply today's most popular choice for CGI applications. Some other widely-used languages are C, C++, TCL, BASIC and - for simple tasks -even shell scripts. Reasons for choosing Perl include its powerful text manipulation capabilities (in particular the 'regular' expression) and the fantastic WWW support modules available.

?: Do I have to call it *.cgi?
$. Yes, and you need to ensure is that they are in the cgi-bin directory.

?: What do I need to know about file permissions and "chmod"?
$. Unix systems are designed for multiple users, and include provision for protecting your work from unauthorised access by other users of the system. The file permissions determine who is permitted to do what with your programs, data, and directories. The command that sets file permissions is chmod. Web servers typically run as user "nobody". That means that, setting aside serious bugs (such as those in certain versions of the FrontPage extensions), your files are absolutely secure from damage through the web server. It also means that you may have to make explicit changes to enable the server to access them in a CGI context. By default they run as the web server user (nobody). For most purposes this is safest, as your programs and data are protected by the operating system from unauthorised access through possible bugs in your CGI. However, when the CGI has to write to a file, that file must be writeable to every web user on the system, and is therefore completely unprotected. Some modes that may be useful in a typical CGI context are:
CGI programs, 755
data files to be readable by CGI, 644
directories for data used by CGI, 755
data files to be writable by CGI, 666 (data has absolutely no security)
Finally, if this answer tells you anything you didn't already know, don't even think about trying to set up a secure server!

?: How do I decode the data in my Form?
$. All Form data is encoded in a string, of the form
param1=value1&param2=value2&...paramn=valuen
Many non-alphanumeric characters are "escaped" in the encoding:the character
whose hexadecimal number is "XY" will be represented by the character string
"%XY" .
To decode a form using GET method:
$variable=ENV{‘QUERY_STRING’};($name, $value) = split(/ & /, $variable);
To decode a form using POST method:
Read ( STDIN, &buffer, ENV { ‘CONTENT_LENGTH’ });($name, $value) = split(/ & /, $buffer);

?: What is HTTP (HyperText Transfer Protocol)?
$. HTTP is the protocol of the Web, by which Servers and Clients (typically browsers) communicate. An HTTP transaction comprises a Request sent by the Client to the Server, and a Response returned from the Server to the Client.

?: What environment variables are available to my application?
$. Use the following script:
!/usr/bin/perl
echo "content-type: text/plain"
echo
set
Save it with any name and run it on your browser. The script returns the default Environment variables. Five important environment variables are available to your CGI script to help in identifying the end user.
HTTP_FROM This environment variable is, theoretically, set to the email address of the user. However, many browsers do not set it at all, and most browsers that do support it allow the user to set any value for this variable. As such, it is recommended that it be used only as a default for the reply email address in an email form.
REMOTE_USER This variable only set if secure authentication was used to access the script. The AUTH_TYPE variable can be checked to determine what form of secure authentication was used. REMOTE_USER will then contain the name the user authenticated under. Note that REMOTE_USER is only set if authentication was actually used, and is not supported by all web servers. Authentication may unexpectedly fail to happen under the NCSA server if the method used for the transaction is not listed in the access.conf file (ie, <Limit GET POST> should be set rather than the default, <Limit GET>).
REMOTE_IDENT This variable is set if the server has contacted an IDENTD server on the client machine. This is a slow operation, usually turned off in most servers, and there is no way to ensure that the client machine will respond honestly to the query, if it responds at all.
REMOTE_HOST This variable will not identify the user specifically, but does provide information about the site the user has connected from, if the hostname was retrieved by the server. In the absence of any certainty regarding the user's precise identity, making decisions based on a list of trusted addresses is sometimes an adequate workaround. This variable is not set if the server failed to look up the host name or skipped the lookup in the interest of speed; see REMOTE_ADDR below. Also keep in mind that you may see all users of a particular proxy server listed under one hostname.
REMOTE_ADDR This variable will not identify the user specifically, but does provide information about the site the user has connected from. REMOTE_ADDR will contain the dotted-decimal IP address of the client. In the absence of any certainty regarding the user's precise identity, making decisions based on a list of trusted addresses is sometimes an adequate workaround. This variable is always set, unlike REMOTE_HOST, above. Also keep in mind that you may see all users of a particular proxy server listed under one address.

?: Can I get the email of visitors?
$. The best information available is the REMOTE_ADDR and REMOTE_HOST, which tell you nothing about the user. Techniques such as "finger@"are not reliable, are widely disliked, and generally serve only to introduce long delays in your CGI. Better - as well as more polite -just to ask your users to fill in a form.

?: Can I trace where a user has come from/is going to?
$. HTTP_REFERER might or might not tell you anything. By all means use it to collect partial statistics if you participate in (say) an advertising banner scheme. But it is not always set, and may be meaningless (eg if a user has accessed your page from a bookmark, and the browser is too dumb to cope with this). The HTTP protocol forbids relying on Referrer information for functionality in your programs, so don't try it. You cannot trace outgoing links at all. If you really must try, point all the external links to your HTTPD and use its redirection facility (which gives you generally-reliable logs). This is much less inefficient than using a CGI script.

?: Why do I get Error 500 ("the script misbehaved", or "Internal Server Error")
$. When faced with an 500 Internal Server Error go through this checklist.
Check for syntax errors in the code.
File permissions for the script may not be proper.
File may have been uploaded in binary, not ASCII.
A wrong PERL path.
A file that the script uses does not exist.
A file needed by the script is not readable to the world.
A file written to by the script is not set writeable by the world.
A directory that the script creates is not writeable by world.
A program executed by the script does not exist, or returns an error.
The script has not content type defined for it.

?: I try to open a file for writing so I can save my data, but the open() command fails. What's going on?
$.    Generally, the HTTP server will be running as user "nobody", or "www", or some other user id that has minimal privileges. As a result, the directory (where you intend to create the file) must be writeable by this process id. To be on the safe side, always check the return status from the open command to see if it was a success:
open (File, "/abc/data.txt") || error ("Could not open file /abc/data.txt);
.
.
.
sub error {
my ($message) = @_;
print <<End of Error;
Content-type : text / html
Status: 500 CGI Error
<HTML>
<HEAD>
<TITLE>CGI Error</TITLE>
</HEAD>
<BODY>
<H1>Oops! Error</H1>
<hr>$message
<hr>
</body>
<html>
End_of_Error
}

?: What are STDERR and STDIN and STDOUT ?
$. In a CGI environment, STDERR points to the server error log file. You can take this to your advantage by outputting debug messages, and then checking the log file later on. Both STDIN and STDOUT point to the browser. In actuality, STDIN actualls points to the server which interprets the client (or browser's) request and information, and sends that to the script. In order to catch errors, you can "dupe" STDERR to STDOUT early on in your script (after outputting the valid HTTP headers):
open (STDERR, ">&STDOUT");

This redirects all of the error messages to STDOUT (i.e the browser).

?: Why shouldn't I have people type in passwords or social security numbers or credit card numbers? Isn't that what TYPE="password" is for?
$.   NO! The forms interface allows you to have a "password" field, but it should not be used for anything highly confidential. The main reason for this is that all form data (including "password" fields) gets sent from the browser to the Web server as plain text, and not as encrypted data. If you want to solicit secure information, you need to use a secure server available commercially.

?: How do I generate separate pages for Netscape vs. the rest of the world?
$. You can have your CGI script determine whether your script is being accessed by Netscape by using the environment variable HTTP_USER_AGENT. Here is an example:
$browser = $ENV{'HTTP_USER_AGENT'}
if ($browser=~ /Mozilla/) {
#
# Netscape
#
} else {
#
# Non Netscape
#
}

?: How come when I run it from the command line, my CGI works, but not from the browser?
$. This most likely is due to permission problems. Remembering your server is probably running as "nobody", "www", or a process with very minimal privileges. As a result, it will not be able to execute your script unless it has permissions to do so.

?: How come my CGI runs fine but doesn't manage to write its output files?
$. Again, this has to do with Permissions! The server cannot write to a file in a certain directory if it does not have permissions to do so. You need to make sure that the directory which you are writing to can be written to by the world. If not, do a chmod 777.

?: How do I check for syntax errors in my script?
$. Load PERL. exe from the numerous sites it is available on, on the CGI internet. Type in the following command from your PERL prompt:
perl> perl-c someprog_ram.pl
This command will list the errors in syntax in the script mentioned.

?: How can I call a CGI without using a <FORM> tag?
$. You can call a CGI program by simply opening the URL to it:
http://4eit.com/cgi-bin/some_program.pl
You can also have a link in a document, such as:
<A HREF="http://www.4eit.com/cgi-bin/some_program.pl">
Click here to access my CGI program</A>

Home | Support | Payment Options | Contact Us | About Us

Domain Name Registration | Linux Web Hosting | Reseller Web Hosting | Free Web Hosting | Free Resource Directory

Group Sites: 2itb.com | AboutD.com | Artcliff.co.uk | 123stones.com