We help IT Professionals succeed at work.

IIS 3.0 arguments passed to cgi script

Steven021997 asked
Medium Priority
Last Modified: 2013-12-25

I've written some cgi scripts for web site 1.1.  Now my ISP is moving to IIS 3.0 and they have given me a few weeks to convert my VB programs to work with IIS 3.0.  

It is a bit annoying; however, I need to know what arguments does the IIS 3.0 pass to the cgi scripts.  For instance, Web site 1.1 passes an .ini filename which contains the name of the file that I should output my data to.  How is this performed with IIS 3.0? Will IIS 3.0 pass a filename to the cgi script? Is it one, two files?  Where can I find more info? or at least what is the format of the data that the server passes to the cgi script?

Watch Question

They can be passed as environment variables. Here is an excerpt from "Microsoft Internet Information Server" by Authur Knowles,

When a CGI script is called, the Web server first examines the REQUEST_METHOD used to call the
CGI script to determine how the Web client is sending data to the CGI script.  If the REQUEST_METHOD used to call the CGI script is GET, any data sup-plied by the Web client for the CGI script is found immediately following the URL name of
the CGI script. Therefore, this information will be stored in the environment variable QUERY_STRING. On the other hand, if the REQUEST_METHOD used was POST or PUT, the size of input for the CGI script is stored in CONTENT_LENGTH. CONTENT_LENGTH contains the size of data sup-plied
to the CGI script in bytes. The CGI script can then read from standard input the number of bytes returned by  CONTENT_LENGTH to find out data given to the CGI script.

Each time the Web server executes a CGI script, it creates a number of environment variables to pass information to the CGI script. These variables inform the CGI script how the script is
being invoked as well as provide information about the server and the Web browser being used by the client. Depending on how the CGI script is invoked, some environment variables may
not be available in some cases.

Environment variables supplied to CGI scripts are always all uppercase. When they are being accessed by a C program or Perl script, or whichever language you are using, be sure to use all uppercase letters.

Sometimes CGI scripts are invoked with additional information. This information is typically input for the CGI program. The length of this additional information is specified by the num-ber
of bytes taken up by the additional information in this variable. If a CGI script is called with the PUT or POST method, CONTENT_LENGTH is used to determine the length of the input.

MIME content types are used to label various types of objects (HTML files, Microsoft Word files, GIF files, and so on). The MIME content type for data being submitted to a CGI script
is stored in CONTENT_TYPE. For example, if data is submitted to a CGI script using the GET method, this variable will contain the value  pplication/x-www-form-urlencoded. This is because re-sponses to the form are encoded according to URL specifications.

The CGI specification revision number is stored in the GATEWAY_INTERFACE environment vari-able. The format of this variable is CGI/revision. By examining this variable, a CGI script can determine the version of CGI that the Web server is using.

Various Web clients can handle different MIME types. These MIME types are described in
the HTTP_ACCEPT variable. MIME types accepted by the Web client calling the CGI script will
be a list separated by commas. This list takes the format type/subtype, type/subtype. For ex-ample,
if the Web client supports the two image formats GIF and JPEG, the HTTP_ACCEPT list
will contain the two items image/gif, image/jpeg.

By looking at this value, the Web browser used by the client can be determined. For example,
if Netscape 2.0 beta 4 is being used by the client, the HTTP_USER_AGENT variable will contain the
value Mozilla/2.0b4 (WinNT; I). The general format of this variable is software/version

The PATH_INFO variable is usually used to pass various options to a CGI program. These op-tions
follow the script’s URL. Clients may access CGI scripts with additional information af-ter
the URL of the CGI script. PATH_INFO will always contain the string that was used to call
the CGI script after the name of the CGI script. For example, PATH_INFO will have the value
/These/Are/The/Arguments if the CGI script FunWithNT.EXE is called with the following URL:

In the event the CGI script needs to know the absolute pathname of itself, the CGI script can
obtain this information from PATH_TRANSLATED. For example, if the CGI script being invoked
is HelloNTWorld.EXE, all CGI scripts are stored in H:\www\http\ns-home\root\cgi-bin, and the
CGI script is accessed with the URL http://your_server.your_domain/root/cgi-bin/
HelloNTWorld.EXE, PATH_TRANSLATED will contain the value H:\www\http\ns-home\root\cgi-bin\
HelloNTWorld.EXE. If the CGI program needs to save or access any temporary files in its
home directory, it can use PATH_TRANSLATED to determine its absolute location by examining
this CGI variable.

You may have noticed that when you submit some forms, there is a string of characters after a
question mark, followed by the URL name of the script being called. This string of characters
is referred to as the query string and contains everything after the question mark. When a CGI
script is called with the GET method, QUERY_STRING typically contains variables and their values
as entered by the person who filled out the form. QUERY_STRING is sometimes used by various
search engines to examine the input when a form is submitted for a keyword search. For ex-ample,
if a CGI application is executed using the URL http://www.server.com/cgi-bin/
application.exe?WindowsNT=Fun, QUERY_STRING will contain the string WindowsNT=Fun.

The IP address of the client that called the CGI program is stored in the REMOTE_ADDR environ-ment
variable. Due to security reasons, the value of this variable should never be used for user
authentication purposes. It’s not very hard to trick your Web server into believing a client is
connecting to your Web server from a different IP address.

If the Web server can do a DNS lookup of the client’s IP address and finds the alias of the IP
address, the REMOTE_HOST variable will contain the alias name of the client’s IP address. Some
Web servers allow DNS lookups to be turned on or off. If you will be using this variable to find
the IP address alias of clients, be sure the DNS lookup option is turned on. The Web server
can find the IP address aliases of most clients, but it might not be capable of getting the aliases
of some clients. In such an event, the REMOTE_HOST variable will not be assigned the client’s DNS
alias value; it will just contain the client’s IP address. This value should never be used for user
authentication purposes.

If the Web server being used supports RFC 931 identification, this variable will contain the
user name retrieved from the server. Unfortunately, this value cannot be trusted when trans-mitting
sensitive data. Typically, a Web server obtains this value by contacting the client that
initiated the HTTP request and speaking with the client’s authentication server. Visit http:
//www.pmg.lcs.mit.edu/cgi-bin/rfc/view?number=931 for additional information about RFC
931 and the Authentication Server Protocol.

Some Web servers support user authentication. If a user is authenticated, the CGI script can
find out the user name of the person browsing the Web site by looking at the value of the
REMOTE_USER environment variable. The REMOTE_USER CGI variable is available only if the user
has been authenticated using an authentication mechanism.

A client can call a CGI script in a number of ways. The method used by the client to call the
CGI script is in the REQUEST_METHOD variable. This variable can have a value like HEAD, POST,
GET, or PUT. CGI scripts use the value of this variable to find where to obtain data passed to the
CGI script.

All files on a Web server are usually referenced relative to its document root directory.
SCRIPT_NAME contains the virtual pathname of the script called relative to the document root
directory. For example, if the document root directory is c:\www\http\ns-home\root, all CGI
scripts are stored in c:\www\http\ns-home\root\cgi-bin\ and the CGI script HelloNTWorld.EXE
is called, the SCRIPT_NAME variable will contain the value \cgi-bin\HelloWorld.EXE. The ad-vantage
of this variable is that it allows the CGI script to refer to itself. This is handy if, some-where
in the output, the script’s URL needs to be made into a hypertext link.

The domain name of the Web server that invoked the CGI script is stored in this variable.
This domain name can either be an IP address or DNS alias.

Typically, Web servers listen to HTTP requests on port 80. However, a Web server can listen
to any port that’s not in use by another application. A CGI program can find out the port from
which the Web server is serving HTTP requests by looking at the value of the SERVER_PORT
environment variable. When displaying self-referencing hypertext links at runtime by examin-ing
the contents of SERVER_NAME, be sure to append the port number of the Web server (typi-cally
port 80) by concatenating it with the value of SERVER_PORT.

Web servers speak the Hypertext Transport Protocol (HTTP). The version of HTTP the Web
server is using can be determined by examining the SERVER_PROTOCOL environment variable.
The SERVER_PROTOCOL variable contains the name and revision data of the protocol being used.
This information is in the format protocol/revision. For example, if the server speaks HTTP
1.0, this variable will have the value HTTP/1.0.

The name of the Web server that invoked the CGI script is stored in the SERVER_SOFTWARE
environment variable. This environment variable is in the format name/version. If a CGI script
is designed to make use of various special capabilities of a Web server, the CGI script can
determine the Web server being used by examining this variable before those special capabili-ties
are used.


I am sorry, perhaps I didn't explain myselft very well.  I wrote my
cgi script in VB (specifically VB4).  I know about the environment
variables.  I know what the data is that gets passed, what I need to know is: What are the arguments being passed from the IIS  to the cgi script.  I know you can use C, or Perl to read in the environment variables.  

Here is an example:  On website 1.1 the server will shell out to the cgi script as such,   " cgi.exe w3k21.ini ".  Website will shell out to a program called cgi.exe and pass w3k21.ini (which is a file).  Inside of the w3k21.ini are the environment variables.  Once the Website 1.1 server notices that the cgi.exe has terminated, the .ini file will be deleted.

My unfortunate situation is that my ISP changed its web server from Website 1.1 to IIS.  I need to know how to make my current cgi scripts work with the new server.  How does my cgi script written in VB4 collect the environment variables?  I know that the IIS does not send an .ini file to the cgi script.  So how does my cgi script get the data?

Hope I was clearer :)


Habitually Visual Basic CGIs use a special interface with web servers, not standard CGI1.1 specs. They are the WinCGI specs defined by Website, where values are passed by the way of files.
A file cgi32.bas is widely available in the internet, allowing VB apps to be ran by WinCGI calls.
By its way, IIS doesn't follows WinCGI specs, but CGI1.1 ones (nearbe), but fortunately, Microsoft has provided some patchs to translate its calls to WinCGI 1.2 specs, and then to allow VB CGIs to work by their classical manner (which are not yours!).
You can find all the needed informations, and cgi32.bas at:


I know it is possible with VB apps to get data from environment, from STDIN and to do outputs to STDOUT as needed with CGI1.1 specs, but VB is works very nice with WinCGI (maybe better).

BTW: what's strange is that you used Website, but without their specific tools!...

'hope this helps...

I think you've three possibilities:

1. look at WebSite-home, there you'll find a wrapper-programm which makes it possible to use the WINCGI interface as an IIS-ISAPI-DLL.(or was it at www.microsoft.com ?? - sorry, I don't remember)

2. you get all the environment variables with VB and make your wrapper inside the program (may be, I'm able to help you)

3. you change your programs from VB to VC++, C++ or Delphi 2.x and build an ISAPI-DLL or an CGI-Standard-application (may be, I can help you too)

All possibilities sound not easy, but you've no other chance - Sorry.



    /   /        /__ /__ /      A-1190  Vienna / Austria
   /__ /        /   /   /      Weinberggasse 60/9/7
  /   /        /   /   /      phone: 0043 (222) 32 83 87
_/  _/artwig _/  _/  _/OTAL  e-mail: moh@bue.magwien.gv.at

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.