CGIproxy
                                written by
                              Scott Leerssen
                         leerssen@issl.atl.hp.com
What is it?
===========

Why would you want to use this?  Well for starters, if you have an NT
web server sitting somewhere and you want to provide access to it
through a UNIX box, this will do the trick.  Or, if you have some very
large applications that are better suited to another machine, but your
main web server is somewhere else, again, this will do the trick.
 
"Why not just redirect," you ask.  Well, in some cases the machine you
want to access my not be accessible from the internet (private subnet,
for instance).  This allows you to (fairly transparently) provide
access to internal (intranet) resources from your external (internet)
web server.


Shortcomings
============

If the proxy-to server is expecting SSL, this won't work.  It would
not be difficult to add SSL support via SSLeay, but if your initial
connection over the internet to the external web server is encrypted,
it's not a big risk if the short hop to some internal server isn't.

If the proxy-to server is expecting user authentication, again, the
cgiproxy won't work, This is because a CGI (the cgiproxy in this case)
is given the username, but not the password in its execution
environment.  Additional NSAPI support could provide this if you
really need it.
 
 
To-do List
==========

cgiproxy only knows how to proxy to one server right now.  It may be
desirable to proxy to a number of servers where resources are
distributed.  When I find a nice, clean way to do this, (and time to
do the work), I'll add said support.
 

Usage
=====

------------------------
For vanilla web servers:
------------------------

Tell the cgiproxy what host has the web server you want to
connect to.  Add a line to your obj.conf to set the HTTPPROX
environment variable:

    Init fn=init-cgi HTTPPROX=<host>[:<port>]
 
where <host> is the name of the host you want your CGI requests
proxied to, and the optional <port> you want to connect to, eg:

    Init fn=init-cgi HTTPPROX=speedy.mydomain.com

                        or
        
    Init fn=init-cgi HTTPPROX=foobar.com:8080

-----------------
For VirtualVault:
-----------------

Tell the cgiproxy what host has the web server you want to
connect to.  Add a field to your tgad.conf to set the HTTPPROX
environment variable:

*/cgiproxy:gw_type=program:gw_env=inside:gw_allowed:\
	gw_environvars%HTTPPROX=speedy.mydomain.com:chkent:

                        or

*/cgiproxy:gw_type=program:gw_env=inside:gw_allowed:\
	gw_environvars%HTTPPROX=foobar.com\:8080:chkent:

---------------
For both cases:
---------------

Then, to proxy the requests, compile this program and place it in your
CGI (usually cgi-bin) directory, then create symbolic links to the cgi
names you want proxied.  Eg.
 
    ln -s cgiproxy somecgi
    ln -s cgiproxy anothercgi
    etc...
        
The CGI programs "somecgi" and "anothercgi" actually live on the host
you are proxying the requests to.  Now, a request for "somecgi" on
your first web server will result in an execution of the cgiproxy,
which, in turn, will make a connection to your other, proxy-to, web
server which will run the actual CGI, return the response through the
cgiproxy and back (finally) to the browser.


Disclaimer
==========

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.