On 06-07 22:46, Raúl Alexis Betancor Santana wrote:
On Monday 06 July 2009 22:13:27 Andrei Pelinescu-Onciul wrote:
On Jul 06, 2009 at 23:41, Juha Heinanen jh@tutpro.com wrote:
i may be wrong, but it is hard for me to believe that python xmlrpclib would be badly broken, because it is very widely used.
The parser is not broken, it works. The problem is how it uses the transport by default. It looks like it waits for the remote close before it starts parsing the reply, which is wrong.
If one changes the transport (like in the example I've sent or in ser_ctl), then it works perfectly. One has only to create a new Transport class and then import it in all his code and instead of:
c=xmlrpclib.ServerProxy("http://" + XMLRPC_SERVER+ ":" + str(XMLRPC_PORT))
use
transport=Transport() c=xmlrpclib.ServerProxy("http://" + XMLRPC_SERVER+ ":" + str(XMLRPC_PORT), transport)
(this will removes the wait for the remote close() and it will work also with mi_xmlrpc)
Umm, re-checking your example and the responses that Juha pasted ... you are wrong, I explain myself ...
xmlrpc responses are sended as HTTP/1.0 transport, SO AS PER HTTP/1.0 RFC, only ONE request/response per conection are allowed so xmlrpclib is waiting for the remote end to close the conection because it see HTTP/1.0 on the headers.
I tend to disagree. The RFC you refer to says that if the response carries Content-Length header field then the value of the header field determines the end of the reply. If there is no Content-Length header field in the reply then the reply is complete when the server closes the connection. Even for HTTP/1.0 requests and responses.
This really is a bug in the xmlrpc client library, because it ignores the Content-Length header field. Unfortunately it is not triggered by most other servers because they close the connection immediately.
Could someone try to check what happens if transport is HTTP/1.1 instead of HTTP/1.0 ?
Nothing, in fact the xmlrpc module returns in reply whatever the client sent in the request.
Jan.