CGI Programs

What is CGI?

CGI (Common Gateway Interface) passes a request from a web page to an application program and receives data back to display to the user. For example, when a user fills out a form on a page, it needs to be processed by an application program. The information from the form is passed to an application program (a cgi script) that processes the data and may send back something - such as a confirmation message.

iiNet offers free web space on certain accounts - to check if your account comes with free web space please contact iiNet support. As an additional unsupported feature, iiNet also allows you to insert programs that employ the Common Gateway Interface (CGI) protocol to add greater functionality to your web pages.

Including CGI scripts on your web page allows you to do simple processing on the iiNet server. We do not provide free technical support for CGI scripts - so if you contact iiNet support regarding CGI scripts we will not be able to help you. However if you want to set them up yourself you can. The CGI script extension should read: .cgi

We have compiled a short tutorial below to help with the most frequently asked questions concerning CGI scripts.

CGI Tutorial

Error Message:

This could be due to the script having an error, which means it could not be compiled and executed correctly. Check the coding and make sure that everything is syntactically correct.

It could also be due to lax security on the script which means the iiNet security model will not let the script run - check the permissions that are set on the script and any files or directories concerned.

Error Message: The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, username@iinet.net.au and inform them of the time the error occurred, and anything you might have done that may have caused the error.

For those familiar with UNIX, the following are reasons are this error would occur:

1. The script is not executable
2. The error level returned from the script was not 0.
3. The web server's security model would not let the script run.
4. Malformed headers were presented.

Having an incorrect error level returned is an indication that something failed to compile or complete. If you are running, say, a Perl script, the Perl interpreter will return a non-zero error level if it can't compile the CGI script completely without errors. Alternatively, your program itself may return an error-level if it didn't complete correctly.

For the most part, you can try and weed out the errors as follows. Let's say you are user "zen", and your CGI script is at the location http://members.iinet.net.au/~zen/myprogram.cgi

Firstly, log into the ftp server members.iinet.net.au with your username and password. Inside the public_html directory:

• Find your failing CGI script (eg. myprogram.cgi)
• Right click on it

• Click on this option
• Set the permissions to one of the following (this will depend on what your FTP client will ask for):
  • 755
  • Read, Write and Execute for Owner, Read and Execute for Group and Read and Execute for All

See below for some common perl errors, but if you're stuck its time to call in an experienced CGI programmer.

Now, assuming the errorlevel is zero, and the execute permissions are right, it could be the script failing our security model. Here is what the script looks for (largely reproduced from Apache's website):

Does the target program have an unsafe hierarchical reference?
Does the target program contain a leading '/' or have a '..' backreference? These are not allowed; the target program must reside within the Apache webspace.

Does the directory in which the program resides exist?
If it doesn't exist, it can't very well contain files.

Is the directory within the Apache webspace?
If the request is for a regular portion of the server, is the requested directory within the server's document root? If the request is for a UserDir, is the requested directory within the user's document root? (/u/x/username/ on iiNet's standard account web server.)

Is the directory NOT writable by anyone else?
We don't want to open up the directory to others; only the owner user may be able to alter this directory's contents.

Does the target program exist?
If it doesn't exist, it can't very well be executed.

Is the target program NOT writable by anyone else?
We don't want to give anyone other than the owner the ability to change the program.

Is the target program NOT setuid or setgid?
We do not want to execute programs that will then change our UID/GID again.

For the most part, really the only one we find users generally stumbling across is file permissions. Ensure your directory is not world writable, and definitely make sure your script is only writable by yourself.

Lastly, the script needs to return valid HTTP. If it isn't doing this by virtue of it failing the above points, then it is simply badly coded.

The script should return like this:

: \r\n

: \r\n

\r\n

The Key/Value pairs are the "header", and there is one mandatory header which is "Content-type". For HTML its value should be "text/html", for text it should be "text/plain", for a GIF it should be "image/gif" etc.

Apache (the iiNet web server) doesn't really care if you use \n rather than \r\n as a line separator. (Note, when we say \r and \n here, \r means a carriage return, and \n means a line feed)

The content should be of whatever form you've specified in the Content-type.

There really aren't many more points of failure, so if you are confident it is producing a syntactically correct HTTP response, and that there are no discernible errors in the code or in the permissions - we can have one of our consultants have a look.

Good Luck!

Common Perl Errors

Since a lot of CGI scripts are written in a language called perl, here are some common traps we run into all the time:

• Make sure all your @ signs in strings (such as email addresses) are escaped with a backslash. i.e. president@whitehouse.gov should be president\@whitehouse.gov

• Ensure the first line reads

    #!/usr/bin/perl
    

  which will point CGI to run the correct perl interpreter..

• Strip carriage returns from your program.

• Our sendmail interpreter is /usr/sbin/sendmail. It is stock standard sendmail. On any of our web affiliate servers, we actually run qmail which isn't stock standard sendmail, although it does understand the more common sendmail switches and conventions.

Click here to return to the Homepages index