Created attachment 1024230 [details] patch to fix urlparse problem on 2.2 Description of problem: The Spacewalk Ubuntu packages from here: https://launchpad.net/~mj-casalogic/+archive/ubuntu/spacewalk-ubuntu Seem to generate package requests in the form of: //XMLRPC/GET-REQ/channelname/getPackage/packagename Since Spacewalk Proxy (particularly the rhnBroker component) uses urlparse to parse the aforementioned url, it interprets the //XMLRPC/ portion as a network location, and drops it from the request it sends to the real spacewalk server. Version-Release number of selected component (if applicable): I'm using 2.2, however, looking at the 2.3 code base, it appears its susceptible to the problem as well. How reproducible: Always. Steps to Reproduce: I've been testing by calling the Ubuntu spacewalk transport directly. Register client in Spacewalk via proxy server (via rhnreg_ks) Then: root@XXXXXXXX:~# cat /tmp/x 600 URI Acquire URI: spacewalk://XXXXXXXXXXXX/XMLRPC/GET-REQ/channel_default_ubuntu1204lts_x8664_spacewalk/getPackage/pyjabber-0.5.0-1.4ubuntu3~precise1.all-deb.deb Filename: /tmp/pyjabber_0.5.0-1.4ubuntu3~precise1_all.deb root@XXXXXXXX:~# <Note the blank line at the end, for a total of 4 lines. The URI: entry is one long single line.> root@XXXXXXXX:~# cat /tmp/x | /usr/lib/apt/methods/spacewalk apt-get -y --force-yes install <package in spacewalk> Will also fail. Actual results: /tmp/pyjabber is not created, and the transport fails with a HTTP 404 error Expected results: /tmp/pyjabber is created. Additional info: I'm not certain how I missed this w/ my previous Ubuntu testing and bug report, but it doesn't work. Its arguable the real problem is the client, but I also don't think Proxy should get confused by these sorts of requests. I also note these style of requests work fine when hitting spacewalk directly. The minor attached patch fixes the problem for me w/ 2.2. It should apply to 2.3 with a little fuzz. There may be other occurrences, I did not audit all usages of urlparse() in the entire spacewalk code base. Till the next one........
Thanks for the excellent bug report and patch David. I agree with everything you said, especially: > Its arguable the real problem is the client, but I also don't think Proxy > should get confused by these sorts of requests. I also note these style of > requests work fine when hitting spacewalk directly. While uris of the form "http://hostname//path" are not a violation of the uri spec they are technically a request for a *different resource* than a uri of the form "http://hostname/path", and so I would say that the real problem is definitely the client. However, I agree that if we're able to handle the (incorrect) request properly then we should, especially if Spacewalk does too. You patch assumes that it is always impossible for us to actually have a (real) netloc but no scheme at that point in the code, and I wasn't able to convince myself of that. So I added one more 'and' clause to the if statement "and effectiveURI_parts.netloc == 'XMLRPC'" to ensure that we can handle this one specific case properly but don't break anything else. Committing to Spacewalk master: 693a3bafef25b087cf282495e794302a4499ad1c
Spacewalk 2.4 has been released.