Coupon Accepted Successfully!


What is CGI programming?

The often-mystified abbreviation CGI, for Common Gateway Interface, refers just to a convention on how the invocation and parameter passing takes place in detail. Invocation means different things in different cases. For a Perl script, the server would invoke a Perl interpreter and make it execute the script in an interpretive manner. For an executable program, which has typically been produced by a compiler and a loader from a source program in a language like C, it would just be started as a separate process. There are a number of different methods Web developers can use to enhance the content of Web pages over and above what simple HTML provides. Most of these methods involve writing little programs or routines using one scripting language or another. The are two basic differences with these methods:


1. Where is the script code located?

2. Where is the script code executed?

The following table summarizes to the above two points for the various methods:


Q1 Where is the script code located ?

Q2 Where is the script code executed ?

Q3 Required HTML file extensions



Ans 1: In files in the CGI-BIN

Ans 2:  directory on the server.

Ans 3: On the server. .shtm or .shtml


If PHP, ColdFusion, ASP

Ans 1: Embedded in the

Ans 2: HTML document.

Ans 3: On the server. .php .cfm .asp

If Javascript

Ans 1: Embedded in the HTML document.

Ans 2: On the user's PC by their browser.

Ans 3: n/a

If Java

Ans 1: In files on the server.

Ans 2: On the user's PC by their browser.

Ans 3: n/a

CGI and Perl

You will often see the term "Perl" used with the term "CGI". The two are NOT the same. CGI programs, or scripts, can be written in a variety of computer languages, including C. CGI is the process by which scripts are run. Perl is the most common language used for writing CGI scripts, and for very good reason. (See the Messin' around with Perl section below).

Because Perl has its' roots in UNIX, many people think that Perl CGI scripts cannot be used on Windows NT Web servers. Not true! Perl CGI scripts can not only run on UNIX and NT servers, but with a little tweaking for "AppleScript", many can run on Macintosh servers as well.

A simple CGI script

 The first task is to write a very simple perl program which just prints out an HTML document. This should include all the usual <head> ... </head> and <title> ... </title> commands. However, there are two things to note. First of all, the first two lines of the print out are special. The first line must be Content-type: text/html so that the browser knows what kind of document it is and therefore how to display it. In his case it is a text document of the subclass HTML. You can also send back plain ASCII documents by using text/plain instead. Sound samples and images also have to have the content type specified appropriately. The second line must be blank (ie it must contain just a line feed). This line is reserved for future development.

The second point is really a tip: Strings in perl programs can span over several lines. This means the main part of your perl program can just be one enormous print statement.


 Write a CGI script as a perl program which just generates a simple HTML document. Add a link to it from your home page and make sure you specify the head, the body, a title and a header as well as some main text. You may want to include some horizontal rules and some links, such as a link back to your home page. The important thing is to make sure it works, because there are plenty of pitfalls even at this stage. Remember to correctly set the permissions for it and for any other files and directories as appropriate, and make sure the first two lines are as above.

Using a C program as a CGI script

 In order to set up a C program as a CGI script, it needs to be turned into a binary executable program. This is often problematic, since people largely work on Windows whereas servers often run some version of UNIX or Linux. The system where you develop your program and the server where it should be installed as a CGI script may have quite different architectures, so that the same executable does not run on both of them.


This may create an unsolvable problem. If you are not allowed to log on the server and you cannot use a binary-compatible system (or a cross-compiler) either, you are out of luck. Many servers, however, allow you log on and use the server in interactive mode, as a “shell user,” and contain a C compiler.

You need to compile and load your C program on the server (or, in principle, on a system with the same architecture, so that binaries produced for it are executable on the server too).

Normally, you would proceed as follows:

1. Compile and test the C program in normal interactive use.

2. Make any changes that might be needed for use as a CGI script. The program should read its input according to the intended form submission method. Using the default GET method, the input is to be read from the environment variable.

QUERY_STRING. (The program may also read data from files—but these must then reside on the server.) It should generate output on the standard output stream (stdout) so that it starts with suitable HTTP headers. Often, the output is in HTML format.

3. Compile and test again. In this testing phase, you might set the environment variable QUERY_STRING so that it contains the test data as it will be sent as form data. E.g., if you intend to use a form where a field named foo contains the input data, you can give the command

setenv QUERY_STRING "foo=42" (when using the tcsh shell)


QUERY_STRING="foo=42" (when using the bash shell).

4. Check that the compiled version is in a format that works on the server. This may require a recompilation. You may need to log on into the server computer (using Telnet, SSH, or some other terminal emulator) so that you can use a compiler there.

5. Upload the compiled and loaded program, i.e. the executable binary program (and any data files needed) on the server.

6. Set up a simple HTML document that contains a form for testing the script, etc.

You need to put the executable into a suitable directory and name it according to serverspecific conventions. Even the compilation commands needed here might differ from what you are used to on your workstation. For example, if the server runs some flavor of Unix and has the Gnu C compiler available, you would typically use a compilation command like gcc -o mult.cgi mult.c and then move (mv) mult.c to a directory with a name like cgi-bin. Instead of gcc, you might need to use cc. You really need to check local instructions for such issues.

The filename extension .cgi has no fixed meaning in general. However, there can be server-dependent (and operating system dependent) rules for naming executable files.

Typical extensions for executables are .cgi and .exe.

CGI Environment Variables 

In order to pass data about the information request from the server to the script, the server uses command line arguments as well as environment variables. These environment variables are set when the server executes the gateway program.


The following environment variable are not request-specific and are set for all requests:


The name and version of the information server software answering the request (and running the gateway). Format: name/version


The server's hostname, DNS alias, or IP address as it would appear in selfreferencing URLs.


The revision of the CGI specification to which this server complies. Format:



The name and revision of the information protcol this request came in with.

Format: protocol/revision


The port number to which the request was sent.


The method with which the request was made. For HTTP, this is "GET",

"HEAD", "POST", etc.


The extra path information, as given by the client. In other words, scripts can be accessed by their virtual pathname, followed by extra information at the end of this path. The extra information is sent as PATH_INFO. This information should be decoded by the server if it comes from a URL before it is passed to the CGI script.


The server provides a translated version of PATH_INFO, which takes the path and does any virtual-to-physical mapping to it.


A virtual path to the script being executed, used for self-referencing URLs.


The information which follows the ? in the URL which referenced this script. This is the query information. It should not be decoded in any fashion. This variable should always be set when there is query information, regardless of command line decoding.


The hostname making the request. If the server does not have this information, it should set REMOTE_ADDR and leave this unset.


The IP address of the remote host making the request.


If the server supports user authentication, and the script is protects, this is the protocol-specific authentication method used to validate the user.


If the server supports user authentication, and the script is protected, this is the username they have authenticated as.


If the HTTP server supports RFC 931 identification, then this variable will be set to the remote user name retrieved from the server. Usage of this variable should be limited to logging only.


For queries which have attached information, such as HTTP POST and PUT, this is the content type of the data.


The length of the said content as given by the client. In addition to these, the header lines received from the client, if any, are placed into the environment with the prefix HTTP_ followed by the header name. Any - characters in the header name are changed to _ characters. The server may exclude any headers which it has already processed, such as Authorization, Content-type, and Content-length. If necessary, the server may choose to exclude any or all of these headers if including them would exceed any system environment limits.

An example of this is the HTTP_ACCEPT variable which was defined in CGI/1.0.

Another example is the header User-Agent.


The MIME types which the client will accept, as given by HTTP headers. Other protocols may need to get this information from elsewhere. Each item in this list should be separated by commas as per the HTTP spec.

Format: type/subtype, type/subtype


The browser the client is using to send the request. General format: software/version library/version.

Test Your Skills Now!
Take a Quiz now
Reviewer Name