From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; SunOS 5.6 sun4u) Description of problem: I am behind a firewall where non-proxyed connections to port 80 and 443 are blocked, except via a non-transparent proxy. I have been trying to use up2date for several days now and kept getting timeouts when I tried to use up2date. Today I put a transparent proxy on port 80 to pass the connections on to the non-transparent proxy, and got further (as far as bug 50891), and it allowed me to identify likely two problems, 1. After the initial couple of proxyed secure connection, up2date is using the insecure port 80 2. These subsequent port 80 connections go direct, ignoring the proxy setting. I have checked that no connections to port 80 are being (non-transparently) proxyed and all secure connections are proxyed. How reproducible: Always Steps to Reproduce: 1. run up2date from behind a firewall.
I have done a bit more checking, and it seems that up2date is making a GET connection to port 80 for https://beta.rhns.redhat.com/... rather that a CONNECT connection to port 443. Hence it will not get past any squid proxys which reject a GET of an https page as illegal.
that sounds like a good canidate. The xmlrpc calls are probabaly handling this correctly, but the GETs are failing. Need to make sure they both handle proxies the same way, and that should fix this.
think i've got a fix for this, should be able to qa it and get it out soon.
The fix for bug 50891 also fixes this.
I have the same Problem with RH EL ES 3.0 with the curren up2date installed. up2date-4.2.5-1 The problem lies in hardware.py where the proxy port is ignored an the connection is ALWAYS made on port 80 if cfg['enableProxy']: server_port = up2dateUtils.getProxySetting() server = string.split(server_port, ':')[0] s.connect((server, 80)) (intf, port) = s.getsockname()