The error message varies; it could be "connection refused", "no route to host", or something else.
You're probably out of luck. Virtually all 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. Most likely, they also did this to prevent email abuse.
Unfortunately, no. There are few if any free servers left these days, and those never allow outgoing socket connections.
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.
Fortunately, as of version 2.2.1, CGIProxy uses an installation wizard,
so it should be an easy process on any platform once you have the
prerequisites installed. Here are the
complete installation instructions.
nph-proxy.cgi on a server and run
./nph-proxy.cgi install" from the command line.
That said, I want to hear about any problems you have with the installation wizard, or anything in the instructions that is not clear. The more you report any problems to me, the easier the installation will be in future versions.
As of version 2.2.1, you no longer need to edit
to configure CGIProxy. There is now a simple configuration menu that lets
you set any configuration variable (except $PROXY_DIR). To access the
configuration menu, run "
./nph-proxy.cgi config" from the
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.
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.
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.
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 email@example.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.
|© 1998-2017 James Marshall||http://www.jmarshall.com/tools/cgiproxy/faq.html|
|Last Modified: May 28, 2017|