print "Content-type: text/plain\n\n";
my $key;
foreach $key ( keys %ENV ) {
    print $key, " = ", $ENV{$key}, "\n";
}
print "---\n";
foreach $key ( keys %INPUT ) {
    print $key, ": ", $INPUT{$key}, "\n"
}
exit(0);
[download]

I did just as you suggested with the following results:

1. With a direct connection, all variables are passed to the .cgi

2. Working through WinProxy, none of the variables are getting passed to the cgi from the form.

What is interesting is that with a direct connection, the HTTP_REFERER variable is form.html while through WinProxy, the HTTP_REFERER variable is the test.cgi? Yet both are being submitted from the same page.

Also, the HTTP_HOST ENV through WinProxy was the IP Address while with a direct connection it was coming through with the domain name.

So in the configuration of the cgi, I used a relative address for the cgi (../cgi-local/test.cgi) instead of the absolute http address, an now WinProxy is passing the variables. Not sure what is happening, but at least it now works.

Thanks for all the insight and suggestions.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

OK, I used CGI to parse the form:

use CGI;
$query = new CGI;
$one = $query->param('one');
$two = $query->param('two');


if ($one) {&one; }
elsif ($two) {&two; }
else {&three; }
[download]

Again, it works fine with a direct connection to the Net (performing &one or &two as necessary), but branches to &three when accessed through a proxy as if $one and $two where none existant.

Any ideas?

I have several ideas.

I work for a company that makes transparent proxy software. Microsoft's proxy products don't behave in the manner that other proxies do. When we have issues with our proxy breaking things, we sniff the network and watch the request come though. Some proxies are extremely sensitive to HTTP requests, and require special formatting of HTTP headers to work correctly. For instance, here's a typical HTTP request from an average program:

GET www.google.com/index.html HTTP/1.0
[download]

This code will fail on most proxies because proxies require an additional header. So the following request will work on most proxies:

GET /index.html HTTP/1.0
Host: www.google.com
[download]

Now this works on virtually every proxy. Except WinProxy. WinProxy requires an additional header, as well as browser identification, so the same request would look like this:

GET / HTTP/1.0
Host: www.google.com
User-agent: Mozilla/4.7 
Remote-Host-Wp: 10.0.3.82
[download]

Aparently the session management part of WinProxy is severely lacking.

So the point to all of this is that writing to WinProxy is extremely difficult (do a query for "WinProxy" in Mozilla's bug tracking database, and see how WinProxy breaks everything). My suggestion is to sniff the request, figure out where the proxy is dying, and use LWP::UserAgent to fake the headers WinProxy requires.

Sorry for the rant :-)

BlueLines

Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.

Sorry, I am VERY new to Perl. Do you mean that I should use CGI to parse the form?

Any ideas or explanation first why it won't work as is through the Proxy?

He means use the CGI.pm module, available from CPAN or quite likely already installed on your system. You're basically re-inventing CGI parameter parsing, which is essentially already mastered in this CGI module. By using the module to do your parsing instead of re-implementing it yourself, we can essentially rule out that part of your code as the problem.