|Summary:||RHN yum plugin sending malformed HTTP/1.1 header to proxy server preventing updates|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Terry Consultant <t.consultant>|
|Component:||m2crypto||Assignee:||Miloslav Trmač <mitr>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||5.0||CC:||doughnut, kraxel, marceln, scott.brynen|
|Fixed In Version:||RHBA-2008-0041||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-01-16 14:18:57 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||246139, 296411|
Description Terry Consultant 2007-05-04 15:33:33 UTC
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).
Comment 1 Terry Consultant 2007-05-04 16:12:36 UTC
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.
Comment 2 Gerd Hoffmann 2007-05-21 16:16:58 UTC
I see this too. Recent errata update (yum-rhn-plugin-0.4.3-2.el5.noarch.rpm) doesn't fix it.
Comment 7 Karl Grindley 2007-08-31 12:19:36 UTC
is there an update for this issue??
Comment 8 Karl Grindley 2007-09-18 16:32:09 UTC
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.
Comment 9 Karl Grindley 2007-09-18 16:41:23 UTC
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
Comment 10 Marcel Nijenhof 2007-09-19 16:11:13 UTC
I can confirm that this sullution works on a i386 and a x86_64 rhel 5 system!
Comment 11 Shannon Hughes 2007-09-19 20:22:30 UTC
mitr, can you take a look at this patch and give your input.
Comment 13 Miloslav Trmač 2007-09-23 20:40:09 UTC
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!
Comment 17 Scott Brynen 2007-10-19 18:52:10 UTC
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.
Comment 18 Clifford Perry 2007-11-02 15:54:57 UTC
*** Bug 243468 has been marked as a duplicate of this bug. ***
Comment 24 errata-xmlrpc 2008-01-16 14:18:57 UTC
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