6 Jul
2009
6 Jul
'09
5:46 p.m.
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:
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.
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) 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
--
Raúl Alexis Betancor Santana
Dimensión Virtual