xmlrpc client call in python does not come back

Question

Using Python 2.6.4, windows

With the following script I want to test a certain xmlrpc server. I call a non-existent function and hope for a traceback with an error. Instead, the function does not return. What could be the cause?

import xmlrpclib
s = xmlrpclib.Server("http://127.0.0.1:80", verbose=True)
s.functioncall()

The output is:

send: 'POST /RPC2 HTTP/1.0\r\nHost: 127.0.0.1:80\r\nUser-Agent: xmlrpclib.py/1.0
.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 106\r\n\
r\n'
send: "<?xml version='1.0'?>\n<methodCall>\n<methodName>functioncall</methodName
>\n<params>\n</params>\n</methodCall>\n"
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: text/xml
header: Cache-Control: no-cache
header: Content-Length: 376
header: Date: Tue, 30 Mar 2010 13:27:21 GMT
body: '<?xml version="1.0"?>\r\n<methodResponse>\r\n<fault>\r\n<value>\r\n<struc
t>\r\n<member>\r\n<name>faultCode</name>\r\n<value><i4>1</i4></value>\r\n</membe
r>\r\n<member>\r\n<name>faultString</name>\r\n<value><string>PVSS00ctrl   (2), 2
010.03.30 15:27:21.395, CTRL, SEVERE,     72, Function not defined, functioncall
, , \n</string></value>\r\n</member>\r\n</struct>\r\n</value>\r\n</fault>\r\n</m
ethodResponse>\r\n'

(here the program hangs and does not return until I kill the server)

edit: the server is written in c++, using its own xmlrpc library

edit: found an issue that looks like the same problem http://bugs.python.org/issue1727418

Answer 1

Most likely, the server you're testing does not close the TCP connection once it has sent the response back to your client. Thus the client hangs, waiting for the server to close the connection before it can return from the function.

Answer 2

As you noticed, this is a bug in the server (the client claims to understand 1.0 and the server ignores that and responds in 1.1 anyway, so doesn't close the socket). Python has a workaround for such buggy servers in 2.7 and 3.2, see this issue, but that workaround wasn't in 2.6.4. Unfortunately, from 2.6.5's NEWS.txt it looks like we haven't backported it to 2.6.5 either. The patch for the workaround in 2.7 is here, perhaps you can try applying it to 2.6.5 yourself if it's just impossible to fix the buggy server...?