I am using xmlrpclib against an internal xmlrpc server.
One of the responses returns integer values, and it raises an exception in "_stringify"

The code for _stringify is (xmlrpclib.py:180 in python2.7):

if unicode:
    def _stringify(string):
        # convert to 7-bit ascii if possible
        try:
            return string.encode("ascii")
        except UnicodeError:
            return string
else:
    def _stringify(string):
        return string


So when "unicode" is available, .encode is called on the parameter (which are the returned objects from the server) which fails for ints.

Without the unicode path it works fine, proven with the following monkey-patch:
xmlrpclib._stringify = lambda s: s

I am using the above patch as a workaround, but a fix to the library should be straightforward, simply checking for AttributeError in the except clause would solve it while retaining the existing functionality.


The traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1387, in _parse_response
    p.feed(response)
  File "/usr/lib/python2.6/xmlrpclib.py", line 601, in feed
    self._parser.Parse(data, 0)
  File "/usr/lib/python2.6/xmlrpclib.py", line 868, in end
    return f(self, join(self._data, ""))
  File "/usr/lib/python2.6/xmlrpclib.py", line 935, in end_struct
    dict[_stringify(items[i])] = items[i+1]
  File "/usr/lib/python2.6/xmlrpclib.py", line 176, in _stringify
    return string.encode("ascii")
AttributeError: 'int' object has no attribute 'encode'

Could you provide a response of your server (pass verbose=True to ServerProxy)?

I have attached the response.
As it is coming from our UMS, I had to redact a few values, but that shouldn't matter.

For reference, they were the host name of my email address, and the hashes of passwords etc.
Our UMS is a bit too chatty!

Thank you. Your server produces a response containing nonstandard type tag "ex:nil" [1].

    <member><name>authority</name><value>ROLE_USER</value></member>
    <member><name>fromDate</name><value><ex:nil/></value></member>
    <member><name>userId</name><value><i4>15</i4></value></member>

xmlrpclib is unable to handle this tag, and error handling is poor. xmlrpclib can handle only standard types and "nil" [2].

What is worse, xmlrpclib silently ignores unsupported tag and interprets following name "userId" as a value of the name "fromDate", and following userId's value 15 as next name and so forth. Your workaround doesn't help since the result is totally broken. You get values as keys and keys as values.

What can we do with this issue?

1. Add better handling of unsupported tags. There is a bug, xmlrpc should detect this case and fail instead of producing unreliable result. This is applicable to 2.7.

2. Add support of some Apache extension tags. This is new feature and can be added in 3.6 only. Not all extension tags can be supported, "ex:serializable" is Java specific. This is separate issue.

Martin, do you agree?

[1] http://ws.apache.org/xmlrpc/types.html
[2] http://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php

Minimal reproducer:

>>> xmlrpclib.loads('<params><param><value><struct><member><name>a</name><value><ex:nil/></value></member><member><name>b</name><value><ex:nil/></value></member></struct></value></param></params>')
(({'a': 'b'},), None)

The workaround for your particular case, Nathan:

    xmlrpclib.Unmarshaller.dispatch['ex:nil'] = xmlrpclib.Unmarshaller.dispatch['nil']

Proposed patch makes xmlrpc unmarshaller to be more strong and raise ValueError instead of returning incorrect value when encounters with unsupported value type. The unmarshaller still skips unknown tags silently if they are occurred outside of the "value" element.

Opened issue26885 for adding support of "ex:nil" and other types.

Serhiy, that workaround worked for my needs, thanks.

New changeset 0d015f6aba8b by Serhiy Storchaka in branch '3.5':
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/0d015f6aba8b

New changeset 8f7cb3b171f3 by Serhiy Storchaka in branch 'default':
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/8f7cb3b171f3

New changeset 7050c9fc1f72 by Serhiy Storchaka in branch '2.7':
Issue #26873: xmlrpclib now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/7050c9fc1f72

I think this patch breaks compatibility between python 2.7 versions. Our rpc server has 2.7.10 Python version, and sends back tuples as responses (first value is a boolean, second is a string). If we connect with a computer, which has 2.7.11 or earlier Python, then it is working flawlessly. When we connect with Python 2.7.12 or later, then it sends this error:
ResponseError: ResponseError("unknown tag u'tuple'",)

As far as I understand, the xmlrpclib should be able to marshal through tuples.