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.
Could someone try to check what happens if transport is HTTP/1.1 instead of HTTP/1.0 ? I think that will run without having to change "transport" on the python script.
Anyway IMHO for more complex applications the default transport should be changed anyway if there's any need for some sort of security (and for that a look at ser_ctl will really pay off: you can authenticate the HTML requests using the transport class defined there and all you need to do on ser side is to add a www_authorize/challenge in the xmlrpc route).
I use twisted when developing that kind of apps, so transport and security it's covered by the framework.
The separator doesn't matter as long as it's some kind of whitespace. We can even get rid of all of them (everything on one line) and it should still work.
It matter for the headers/body boundary and for the body/endDoc boundary, you are right saying that you could send the response in one line if you want, XML-spec's allows that, BUT not for the HTTP transport