Description of problem: I am using yum-rhn-plugin 0.4.3-1.el5 and yum 3.0.1-5.el5. I am trying to use a proxy (Apache's mod_proxy) to access RHN. Every time I get the following accesses and errors in the proxy logs: "CONNECT xmlrpc.rhn.redhat.com:443 HTTP/1.1" 200 - "-" "rhn.rpclib.py/$Revision: 102540 $" "CONNECT xmlrpc.rhn.redhat.com:443 HTTP/1.1" 200 - "-" "rhn.rpclib.py/$Revision: 102540 $" "CONNECT xmlrpc.rhn.redhat.com:443 HTTP/1.1" 400 298 "-" "-" [error] [client xxx.xxx.xxx.xxx] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): / When I snoop the traffic to the proxy server, I see that the first 2 requests make it through successfully because they send a CONNECT, a CRLF, and a Host: header. The third request tries to send a CONNECT string, and 2 CRLFs. This makes the proxy unhappy because it violates HTTP/1.1. Let me know if there is more information I can provide. Additional info: rhn_register has a similar problem operating through an Apache proxy. The curses-based version declares failure to register a host when in fact it has partially registered a host (the host shows up in rhn.redhat.com).
Additionally, I have tested going to other non-rhn repos with yum on the same machine, through the same proxy. They all worked fine once I disabled the rhn plugin.
I see this too. Recent errata update (yum-rhn-plugin-0.4.3-2.el5.noarch.rpm) doesn't fix it.
is there an update for this issue??
Created attachment 198561 [details] M2Crypto proxy Host: header patch Brute force fix to add the "Host:" header to make mod_proxy's strict RFC checking happy.
I have hacked together a simple fix and tested with mod_proxy. The issue is two different python calls are being made to connect via the proxy, and one breaks RFC causing mod_proxy to throw a 400 bad request. (thanks to Terry for tracking down the exact problem!) The bug is really in the httpslib.py in the m2crypto-0.16-6.el5.1 package. Here's a simple one line hack/fix for the bare minimum to make mod_proxy happy. (i have not tested this fix via squid or other proxies, although not sure why this would break anything since we're just adding the Host: header directly to the request sent to the proxy) Patch was generated on a x86_64 machine, but I've tested that it applies cleanly on a 32bit/i386 arch. to apply to your system, follow these directions: -download the patch file -x86_64: cd to /usr/lib64/python2.4/site-packages/M2Crypto -i386: cd to /usr/lib/python2.4/site-packages/M2Crypto -patch the file: patch -p0 < /[path to your patch]/rhn-mod_proxy-fix.patch
I can confirm that this sullution works on a i386 and a x86_64 rhel 5 system!
mitr, can you take a look at this patch and give your input.
The patch works fine (tested with squid and mod_proxy); I have sent it upstream and added it to rawhide m2crypto-0.18-2. Karl, thank you!
I can confirm that this bug occurs and is solved with the patch to add the Host with a Sophos WS1000 web security appliance as well. This bug should also be marked as applying to all RH5 hardware platforms.
*** Bug 243468 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0041.html