Network31 Web Design and Hosting

CGI-Bin Support

CGI stands for "Common Gateway Inferface," a fancy name meaning computer programs running on the webserver that can be invoked from a www page at the browser. The "bin" part alludes to the binary executables that result from compiled or assembled programs. It is a bit misleading because cgi's can also be Unix shell scripts or interpreted languages like Perl. CGI scripts need to be saved in ASCII format and uploaded to your server's cgi-bin in ASCII or text format. This is very important.

We don't provide free support for CGI scripts which we did not install on your server. So if you are not already familiar with CGI scripting, you may want to read a book on the subject or find places on the Internet with CGI scripting information. There are many good resources for CGI scripts found on the web. The scripts at Matt's Script Archive found at http://www.worldwidemart.com/scripts/ are very good. Many of our scripts come from here. Another excellent resource is The CGI Resource Index found at http://www.cgi-perl.com/ -- if you are not an expert, look for scripts that are very well documented and come with step-by-step instructions, or contact us for help or installation.

Active Server Pages

There's nothing specific to our server in the way in which you use Active Server Pages. It's just a matter of creating the files and sending them up to the server. All accounts have Active Server Pages enabled.

Also, make sure to check the The "Best" ASP Resource in the World (that's their title). They have a good collection of step-by-step tutorials on a number of introductory and advanced topics.

15 Seconds has regular articles on advanced scripting techniques, focusing on ASP and related items.

Perl CGI

All perl scripts must have a ".pl" or "cgi" extension. Eg. perlscript.pl or perlscript.cgi

CGI.pm: This perl 5 library uses objects to create Web fill-out forms on the fly and to parse their contents. It provides a simple interface for parsing and interpreting query strings passed to CGI scripts. However, it also offers a rich set of functions for creating fill-out forms. Instead of remembering the syntax for HTML form elements, you just make a series of perl function calls. An important fringe benefit of this is that the value of the previous query is used to initialize the form, so that the state of the form is preserved from invocation to invocation. [More...]

There are some basic style considerations to be made when creating CGI scripts in Perl to run on Windows NT. Please check the PerlIIS homepages first if you are having problems receiving the proper behavior from your scripts.

Server Side Includes

SSI is included in all our account types. Due to the method in which SSI is coded into Microsoft Internet Information Server (IIS) however, no EXEC includes are allowed and will generate errors.

All SSI pages must end with the extension ".shtml", ".shtm", or ".stm" in order to be handled correctly.

If you're in need of more information, there is a Server Side Tutorial we've found that may be a good place to start learning more about them. This tutorial does include information on exec style SSI's as it's about SSI in general, and not aimed at NT specifically.

Where to Put CGI-bin Scripts

Put your cgi-bin scripts in the www subdirectory named "cgi-bin".

Troubleshooting CGI-bin Problems

Below are solutions to some of the more common CGI script problems, in question and answer format.

When I activate my CGI program, I get back a page that says "Internal Server Error. The server encountered an internal error or misconfiguration and was unable to complete your request.

This is generally caused by a problem within the script. Log in and test your script in local mode to get a better idea of what the problem is. To do this, go into the directory in which your script is located, then execute the script. To execute the script, you can do it by two ways:

1) Type "perl myscript.pl" (Perl being the language interpreter in this case).

2) Or simply type "myscript.pl" alone, that will work if the first line is well written to indicate the location of Perl.

The first one is useful to see if there's any error IN your script. The second one is useful to test if your "calling line" (the first line of the script) is okay, i.e. if you entered the right location of Perl.

I am being told "File Not Found," or "No Such File or Directory.

Upload your Perl or CGI script in ASCII mode, not binary mode.

When I test my Perl script in local mode (by Telnet), I have the following error: "Literal @domain now requires backslash at myscript.pl line 3, within string. Execution of myscript.pl aborted due to compilation errors.

This is caused by a misinterpretation by Perl. You see, the "@" sign has a special meaning in Perl; it identifies an array (a table of elements). Since it cannot find the array named domain, it generates an error. You should place a backslash (\) before the "@" symbol to tell Perl to see it as a regular symbol, as in an email address.

I am getting the message "POST not implemented.

You are probably using the wrong reference for cgiemail. Use the reference /cgi-bin/cgiemail/mail.txt. Another possibility is that you are pointing to a cgi-bin script that you have not put in your cgi-bin directory. In general, this message really means that the web server is not recognizing the cgi-bin script you are calling as a program. It thinks it is a regular text file.

It's saying I don't have permission to access /

This error message means that you are missing your index.htm file. Note that files that start with a "." are hidden files. To see them, type ls -al. If you wish to FTP this file in, go to the home/yourdomain directory.

Acceptable Use Policy

For Further Information, Contact:

info@Network31.net