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),
allowed me to identify likely two problems,
1. After the initial couple of proxyed secure connection, up2date is using
insecure port 80
2. These subsequent port 80 connections go direct, ignoring the proxy
I have checked that no connections to port 80 are being (non-transparently)
proxyed and all secure connections are proxyed.
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
The problem lies in hardware.py where the proxy port is ignored an
the connection is ALWAYS made on port 80
server_port = up2dateUtils.getProxySetting()
server = string.split(server_port, ':')
(intf, port) = s.getsockname()