Heh, Yes - would you like to lobby RedHat to change their up2date client?? I think the reason they've done this is because it's much more efficient. Not only do they not have to read the body, they don't have to parse it. Also, xml-rpc is totally screwed because it doesn't have a file type, and the normal binary limitation is 8192 bytes of parsable data between two tags :( Alan

Hi,

Am Di, den 12.10.2004 schrieb Alan Milligan um 0:16:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

I had a client that used to work on 2.7.0, and now doesn't on 2.7.3.

The problem would appear to be that it's not substituting the xmlrpc.Response class for a GET request on a text/xml content type and therefore just delegating to the str() function instead of wrapping it in the xml-rpc xml response tags.

I'm a little confused about this, as this only appears to happen in HTTPRequest::processInputs which didn't seem to be invoked for my xml-rpc call anyway ...

tcpdump follows for the sceptics ...

j.. 08:05:04.901469 IP mistress.balclutha.org.34257 > mistress.balclutha.org.zope: P 1:456(455) ack 1 win 32767 <nop,nop,timestamp 225097763 225097723> E.....@.@.)..............W.....x........... j..GET /last-bastion.net/junk/rpm/RPC2/$RHN/mail/listPackages/1 HTTP/1.1 Host: localhost:8080 Accept-Encoding: identity x-client-version: 1 x-transport-info: Extended Capabilities Transport (C) Red Hat, Inc (version 1.40) x-up2date-version: user-agent: rhn.rpclib.py/$Revision: 1.40 $ x-rhn-transport-capability: follow-redirects=1 x-rhn-auth-channels: ['mail', '1'] content-type: text/xml x-info: RPC Processor (C) Red Hat, Inc (version 1.44)

Your log is a bit confusing maybe you better use tcpflow for dumping. But what is clearly seen is the GET request. I wonder how this ever was supposed to work since XML-RPC requires an entidy body for the message (which is in XML). You can compare with RFC2616 - there is no entidy body in GET. Your client needs to use POST. I suspect then it should work.

Regards Tino