I've been developing an application which uses fuse as in interface to an xmlrpc API. I developed it with python 3.4 and it worked fine. When I used python 3.5 it started randomly raising a specific error when requesting info using the xmlrpc API.The error in question is the RemoteDisconnected error which was added in 3.5. An example stacktrace is:Traceback (most recent call last):  File "/home/jelte/fun/easyfuse/easyfuse/utils.py", line 20, in _convert_error_to_fuse_error    yield  File "/home/jelte/fun/easyfuse/easyfuse/filesystem.py", line 276, in children    self.refresh_children()  File "dokuwikifuse.py", line 139, in refresh_children    pages = dw.pages.list(self.full_path, depth=self.full_depth + 2)  File "/home/jelte/fun/dokuwikifuse/venv/src/dokuwiki-master/dokuwiki.py", line 102, in list    return self._dokuwiki.send('dokuwiki.getPagelist', namespace, options)  File "/home/jelte/fun/dokuwikifuse/venv/src/dokuwiki-master/dokuwiki.py", line 55, in send    return method(*args)  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1091, in __call__    return self.__send(self.__name, args)  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1431, in __request    verbose=self.__verbose  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1133, in request    return self.single_request(host, handler, request_body, verbose)  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1146, in single_request    resp = http_conn.getresponse()  File "/usr/lib64/python3.5/http/client.py", line 1174, in getresponse    response.begin()  File "/usr/lib64/python3.5/http/client.py", line 282, in begin    version, status, reason = self._read_status()  File "/usr/lib64/python3.5/http/client.py", line 251, in _read_status    raise RemoteDisconnected("Remote end closed connection without"http.client.RemoteDisconnected: Remote end closed connection without responseThe program in question can be found here:https://github.com/JelteF/dokuwikifuseThe bug can be initiated by calling running the program as described in the README and doing a couple of file system operations wich do requests. These are things like `ls wiki/*` or calling `head wiki/*.doku`.

A short look through the stacktrace actually seemed to have gotten me to the issue. It is in the xmlrpc.client library in this piece of code:         for i in (0, 1):             try:                 return self.single_request(host, handler, request_body, verbose)             except OSError as e:                 if i or e.errno not in (errno.ECONNRESET, errno.ECONNABORTED,                                         errno.EPIPE):                     raise             except http.client.RemoteDisconnected:                 if i:                     raiseAs can be seen http.client.RemoteDisconnected error is caught after the OSError one. However http.client.RemoteDisconnected is a subclass of OSError since it's a subclass of ConnectionResetError:https://docs.python.org/3/library/http.client.html#http.client.RemoteDisconnectedA simple fix which seems to work for me is switching the two except branches as I did in the attached patch.

The code in question[0] was introduced inissue 3566: perhaps Martin could comment on existing implementation.[0]https://hg.python.org/cpython/rev/eba80326ba53

From what I can see that change simply replaces the old BadStatusLine exception with the new RemoteDisconnected one. But since BadStatusLine is not a subclass of OSError the correct code path would be taken. Currently the path in execpt RemoteDisconnected is simply a no-op as the exception will be caught first as an OSError.

Thankyou Jelte for finding this. We made RemoteDisconnected inherit from ConnectionResetError (and therefore OSError) thinking it would help with compatibility, but in this case that has backfired. Your patch looks like a valid fix.I would like to figure out a concise way to produce the fault so I can add a test case and play with the code. Would I be able to use Python’s XML-RPC server, or would I have to make a custom server that dropped the connection?Also I suspect both exception handlers in the XML-RPC client could be combined as “except ConnectionError”, but I want to be sure before making that change.

I don't know much about the server as I only used the client. So I don't know if it is possible to test with Python's XML-RPC server. As for your proposed improvement, it seems that should work. Keep in mind though that that would also catch the ConnectionRefusedError, which is currently raised on the first try. I'm not entirely sure when this is raised, but this might be reasonable behaviour as refusal should probably not be a one time thing. So if that is the case the new except should probably look like this:except ConnectionError:    if i or isinstance(ConnectionRefusedError):        raiseThis does definitely look cleaner than the two different except blocks IMHO. It also makes it clear why the new class is a subclass of ConnectionError.

Here is patch with a test case. I kept Jelte’s original fix as it is, because I want to be conservative in the code changes.Xmlrpc.server only uses HTTP 1.0, without any support of keep-alive connections, so I used http.server instead.

New changesetd668b5595534 by Martin Panter in branch '3.5':Issue#26402: Fix XML-RPC client retrying after server disconnectionhttps://hg.python.org/cpython/rev/d668b5595534New changeset70bf0d764939 by Martin Panter in branch 'default':Issue#26402: Merge XML-RPC client fix from 3.5https://hg.python.org/cpython/rev/70bf0d764939

Thanks for reporting this Jelte

No problem, I'm glad to have contributed something to the language I use the most.