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.
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. It's usually a matter of:
nph-proxy.cgionto your Web server,
./nph-proxy.cgi init" once, and
See the full installation instructions for details.
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.
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 firstname.lastname@example.org. 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: January 29, 2017|