Hello.
Noticed that /WebGUI/Operation/Statistics.pm does not seems to take into account proxy settings. It doesn't use LWP, so I don't know how to fix it in the code.
When I view the statistics I see:
I've talked with support many times, and have established with them that my proxy settings are correct. I've posted other related proxy issues as well. Please let me know if I can try any code fixes for this.
Thanks!
LN
Yes. I didn't know if it was fixed in any of the betas.. I'm still running 7.2.1 ans waiting for the next stable release. But I'll be happy to try the of the betas since our site isn't quite live yet.
According to my research into this, this lookup is done by WebGUI::Cache.pm, in the setByHttp method.
Line 219 (at least in head it's 219) has the env_proxy method call required to enable following proxy information. The line was added back in the 7.1 series, so you should have it.
Would you please check that out?
I have 7.2.1, and YES, In lib/WebGui/Cache.pm, I do see env_proxy on line 219.
Very strange, I followed the code from the Statistics.pm to the Cache.pm file, and I'd come to the same conclusions. But I've been only looking at Perl for a couple of months.
<time elapses>
OH!! I just tried:
w3m http://update.webgui.org/latest-version.txt
and I was able to get to the file.
but when I tried
w3m http://update.webgui.org/latest-version.txt:80 I got a "the requested URL /latest-versin.txt:80 was not found on this server"
Maybe that helps? Maybe you can't use ports for non HTML pages? I've never heard of that.
What a bugger!!! FYI, I've also tried clearing the cache, to force it to renew the information, but with no luck.
You might be on to something with the non-html page, but your second url is wrong. It should be:
w3m http://update.webgui.org:80/latest-version.txt
The port goes on the end of the hostname, not the URL.
Would you try that and see if it works, please?
Dang. I'm lower on sleep than I thought.
web4> w3m http://update.webgui.org/latest-version.txt
Works just fine. =(
What I find interesting is that it gets to the point in the code that it's providing the link to the download file, which is found in the WebGui/Operations/Statistics.pm file. Line 121. So maybe the <if> statement is incorrect?
Doing this over email is slow. Can you hop onto WebGUI's IRC channel?
#webgui on irc.freenode.net
In the meantime, inside WebGUI::Cache::setByHTTP, trying commenting out this line:
$userAgent->timeout(30);
That will force it to use the default timeout, which is longer.
No, I'm about ready to head home.
How about this? On this page
http://www.webgui.org
There is a big button labeled IRC. It will bring up a Java IRC client. I don't suppose that you have a JRE installed?
I'm hoping that in the last few months that you may have upgraded and the bug has gone away.
Any such luck?
Hi. meant to report on this long ago, error still persists. I just upgraded to 7.4.40 and bug still exists. Tried commenting out timeout line in /Cache.pm with no change of error message.
Ive had problems before with env_proxy, and was able to fix testEnvironment.pl. testEnvironoment still works, so I compared the code between the two and modified Cache.pm to do pretty much the same thing, but still doens't get the latest version. I was sure to clear my cache via command line between changes as well. The error I get: "500 Can't connect to update.webgui.org:80 (connect: Connection refused)" is linking to something that is a bit unexpected. It's linking to:
http://update.webgui.org/500%20Can't%20connect%20to%20update.x.x/webgui-500%20Can't%20connect%20to%20update.webgui.org:80%20(connect:%20Connection%20refused).tar.gz
Maybe that helps.
I literally copied and pasted the testenvironment code into Operation/Statistics.pm:
my $currentversionUserAgent = new LWP::UserAgent; $currentversionUserAgent->env_proxy; $currentversionUserAgent->agent("WebGUI-Check/2.1"); $currentversionUserAgent->timeout(30); $currentversionUserAgent->env_proxy(); my $header = new HTTP::Headers; my $referer = "http://".`hostname`."/webgui-cli-version"; chomp $referer; $header->referer($referer); my $currentversionRequest = new HTTP::Request (GET => $url, $header); my $currentversionResponse = $currentversionUserAgent->request($currentversionRequest); my $version = $currentversionResponse->content; chomp $version;
and commented out al the caching code all the way upto the output statements, and I'm STILL getting can not connect. But all my httpproxes work, my testEnvironment work fine thru my proxy. I would have thought this would be easy, but I'm going to have to leave this one to the pros.
ok. I figured out where the "weird" link is coming from.
From what I can see, Operation/Statistics.pm calls Cache->new. Cache->new tries to do a FileCache, it fails, returns an error message. Operation/Statistics.pm stores the error message to $version, skips over the "if (not defined $version) {" check, does NOT call Cache/setByHTTP, but instead prints out what it got from Cache-new, hence my weird hyperlink.
This is where I'm not quite sure what I'm seeing: Operation/Statistics.pm is calling Cache->new with a namespace of "URL" which doesn't seem to be handled. I would think that "URL" should be handled and call setByHTTP. But it doesnt.
Am I close? =)
How do you have the proxy set? Are you certain Apache is getting the proxy environment settings? Try using the SetEnv directive in your modperl config to set the proxy settings.
Yep, I'm 100% convinced that the env is set properly. testEnvironment.pl works, my http proxy pages work, rss feeds work.
My env is:
PROXY=proxy.comtrol.comPROXYPORT=9732NO_PROXY=localhost, 127.0.0.1, 204.73.219.0, .comtrol.comno_proxy=localhost, 127.0.0.1, 204.73.219.0, .comtrol.comftp_proxy=http://proxy.comtrol.com:9732FTP_PROXY=http://proxy.comtrol.com:9732https_proxy=http://proxy.comtrol.com:9732HTTPS_PROXY=http://proxy.comtrol.com:9732HTTP_PROXY=http://proxy.comtrol.com:9732http_proxy=http://proxy.comtrol.com:9732
But I can try setting up setEnv. What conf files do I put those in?mod_perl.conf file?
Either modperl.conf or the vhost config file for your site.
Did using setEnv correct the problem?