The error message varies; it could be "connection refused", "no route to host", or something else.
You may be out of luck. Most free CGI servers have disabled outgoing socket connections, which are required for CGIProxy to connect to any remote server. Based on some hostile emails received by users of CGIProxy, I suspect that some of those free servers disabled outgoing sockets specifically to prevent use of CGIProxy. When the first version was released in late 1998, it worked fine on all those servers. Soon after, they started terminating accounts without warning and sending nasty emails to users of CGIProxy. Eventually they just disabled all outgoing socket connections. (They may also have done it to prevent email abuse.)
So if you try CGIProxy on a free server and it doesn't work, you may have to pay for an account somewhere. If you find a free server where it works, please let me know.
Here's a list of free servers and how well they support CGI scripts. The owner says he keeps it pretty well up-to-date. Unfortunately, the status of each server changes, and few if any allow the use of sockets that CGIProxy needs.
If you find any reliably good free servers for CGIProxy, please tell me. In the meantime, you may have to pay for an account somewhere. Many servers offer accounts that support CGI for as little as $10 (USD) per month, though there may be bandwidth restrictions. Some will automatically charge you extra if you go over your bandwidth allotment, so be careful! Monitor your bandwidth usage until you get used to it. CGIProxy by its nature uses a lot of bandwidth.
Unfortunately, I don't have time to do that. However, Zoltan Milosevic has set up an online automatic installer for CGIProxy which may do what you need. If you're installing on a Windows machine, check out Bennett Haselton's downloadable automatic installer for CGIProxy.
There is no single way to install a CGI script; it varies depending on server configuration. You should ask your webmaster for instructions, or read the server documentation. Many ISP's have Web pages explaining how to install CGI scripts on their servers.
If you've never installed a CGI script before, then I recommend finding a simple one to install first so you can get familiar with the process. Here's one very simple script. Here are some hints that may help.
Even if you've installed CGI scripts before, but you can't get CGIProxy working, I recommend installing a simple CGI script to make sure you're doing everything right.
Having said all that, CGIProxy is normally very simple to install.
Usually, you can just upload the file nph-proxy.cgi onto your Web
server and change the permissions to make it executable
("chmod 755 nph-proxy.cgi" usually does it), and it
will work.
If you don't know Perl, you can guess how to set an option's value by emulating the examples already in there. Variables starting with "$" hold single values, and variables starting with "@" hold lists of values. Lines beginning with "#" are comments and are ignored when the program runs. As in most programming languages, 1 means true and 0 means false. Also as in most programming languages, values that are text-like and not numbers (like server names or IP addresses) are called "strings" and should be enclosed in single or double quotes.
The reason all the options don't go in a separate configuration file is because that would require the script to open and read the file with every call, which would put a major load on the CPU.
From what I hear, most problems with installing CGIProxy on Windows are actually problems with other things, like installing Perl correctly or configuring the server software. Once everything is set up correctly, then installing CGIProxy is reportedly very easy. For help with installing Perl on Windows, here are some links from a user who found them helpful:
http://www.cyonara.com/software/btwin2k/perl.html
http://www.iisanswers.com/Top10FAQ/t10-installperl.htm
http://www.homepages.dsu.edu/waldnerm/docs/perl-install.htm
If you have desktop access to the server machine, then you can automatically install CGIProxy, Perl, and a Web server all at once with Bennett Haselton's automatic installer for CGIProxy. This is probably the simplest way to install CGIProxy for non-technical users.
If your server is IIS and you're having trouble, then see the next question.
IIS has a few bugs in the way it handles paths in URLs and the PATH_INFO variable. When you get this error, CGIProxy is not even running in the first place, because IIS isn't finding it.
To configure IIS to handle PATH_INFO correctly, see this page. You may also need to "uncheck the 'Check that file exists' checkbox for the script map in MMC," according to one user. This patch may be needed too. IIS has other bugs handling PATH_INFO, but CGIProxy works around those once it is found and run correctly.
Note that the first page above is completely wrong when its says there is a security risk with using PATH_INFO. There is NO security risk with using PATH_INFO, and any risk with PATH_TRANSLATED is dubious at best. Either Microsoft is intentionally deceptive here, or they don't know what they're talking about.
Here's (unverified) advice from one user: "For version 5 of IIS I believe the only required changes are in the 'Application Configuration' box on the 'Scripts' properties page, which are editing the *.pl extension mapping and removing the 'Check that file exists' checkbox." Another user says he only had to uncheck the "Check that file exists" checkbox. Yet another user says that doing the same for the *.cgi extension solved his problem.
Basically, the reasons for it don't matter nearly as much as they used to, and there are many benefits to putting it all in one script. The original reason for two scripts was because it was a waste of CPU to use SSL for everything, even when visiting non-secure sites. However, computers are much faster now and continue to get faster. Also, people tend to like secure connections anyway when using this software. The benefits to the one-script version include better cookie coordination between secure and non-secure servers (some popular sites weren't working with the two-script version), and MUCH (!) easier maintenance than the two-script version.
If you have a need for the two-script version, let me know. If there is demand, it shouldn't be hard to add an option in a future release to run as two separate scripts.
Hard to say. A release date is not driven by the calendar, but by when I think the feature set and fixes are complete and good enough to be released. From past experience, releases come out about once every 6-9 months, but it could be much longer or shorter. More and bigger changes usually mean more time between releases. Usually.
If you want to be notified whenever a new version of CGIProxy is released, you can subscribe to get an email whenever that happens, using the free service provided by freshmeat.net. freshmeat is a great site for following software releases, and in general is a great service to the open source community-- lots of good info and services, signup is free, and they don't spam you or anything like that.
Good question. Basically, it's free for non-commercial use, and licensable for commercial use. If you want to license CGIProxy to use in a commercial environment, drop me a line at... oh, let's say sales@jmarshall.com. Common commercial uses include VPN functionality (e.g. giving remote employees access to an intranet or licensed databases), subscriber-based anonymizing proxy sites, use as a component of a larger solution, certain situations requiring FIPS approval, and others. It's a general purpose tool, so I keep hearing new uses for it.
| Last Modified: May 24, 2005 | http://www.jmarshall.com/tools/cgiproxy/faq.html |