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(a)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.