Environment variables

The following environment variables 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 self-referencing URLs.


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

The following environment variables are specific to the request being fulfilled by the gateway program:


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.

CGI Process.

a. How do I get information from the server?

Each time a client requests the URL corresponding to your CGI program, the server will execute it in real-time. The output of your program will go more or less directly to the client.

A common misconception about CGI is that you can send command-line options and arguments to your program, such as

command% myprog -qa blorf

CGI uses the command line for other purposes and thus this is not directly possible. Instead, CGI uses environment variables to send your program its parameters.

The two major environment variables you will use for this purpose are:


QUERY_STRING is defined as anything which follows the first ? in the URL. This information could be added either by an ISINDEX document, or by an

HTML form (with the GET action). It could also be manually embedded in an HTML anchor which references your gateway. This string will usually be an

information query, i.e. what the user wants to search for in the archie databases, or perhaps the encoded results of your feedback GET form.

This string is encoded in the standard URL format of changing spaces to +, and encoding special characters with %xx hexadecimal encoding. You will need to decode it in order to use it.

If your gateway is not decoding results from a FORM, you will also get the query string decoded for you onto the command line. This means that each word of the query string will be in a different section of ARGV. For example, the query string "forms rule" would be given to your program with argv[1]="forms" and argv[2]="rule". If you choose to use this, you do not need to do any processing on the data before using it.


CGI allows for extra information to be embedded in the URL for your gateway which can be used to transmit extra context-specific information to the scripts. This information is usually made available as "extra" information after the path of your gateway in the URL. This information is not encoded by the server in any way.

The most useful example of PATH_INFO is transmitting file locations to the CGI program. To illustrate this, let's say I have a CGI program on my server called /cgi-bin/foobar that can process files residing in the DocumentRoot of the server. I need to be able to tell foobar which file to process. By including extra path information to the end of the URL, foobar will know the location of the document relative to the DocumentRoot via the PATH_INFO environment

variable, or the actual path to the document via the PATH_TRANSLATED environment variable which the server generates for you.

2. How do I send my document back to the client?

The formatting of the output should be done properly so the server can understand it.

CGI programs can return a myriad of document types. They can send back an image to the client, and HTML document, a plaintext document, or perhaps even an audio clip. They can also return references to other documents. The client must know what kind of document you're sending it so it can present it accordingly. In order for the client to know this, your CGI program must tell the server what type of document it is returning.

In order to tell the server what kind of document you are sending back, whether it be a full document or a reference to one, CGI requires you to place a short header on your output. This header is ASCII text, consisting of lines separated by either linefeeds or carriage returns (or both) followed by a single blank line. The output body then follows in whatever native format.

5. What is an Alias?

The Alias directive creates a virtual document (or directory) on your server. Any accesses to it will be satisfied by a different file or directory.
6. What is a Script Alias?

The ScriptAlias directive creates a virtual directory on your server. Any accesses to that virtual directory will be satisfied by returning the output of a CGI server script in that directory.

a. Why We need it:

Apache recognizes all files in a directory named as a ScriptAlias as being eligible for execution rather than processing as normal documents. This applies regardless of the file name, so scripts in a ScriptAlias directory don't need to be named "*.cgi" or "*.pl" or whatever. In other words, all files in a ScriptAlias directory are scripts, as far as Apache is concerned.

7. What is a Redirect?

The Redirect directive creates a virtual document on your server, and any accesses to it will be redirected to a new URL.