[Xen-devel] Re: Re: [RFC][PATCH] Secure XML-RPC for Xend

[Anthony Liguori <aliguori@xxxxxxxxxx>]

On Fri, 09 Jun 2006 11:45:46 -0400, Daniel Veillard wrote:
>> I think Daniel is suggesting that we use HTTP Keep-Alive which I also
>> think is a really good idea.  I think this will come in handy regardless
>> of whether we use SSH.
> 
>   Activating Keep-Alive would be a really good idea in any case,
> local or remote, direct auth or tunnelling ! IIRC the main question
> was about activating it at the Python level, that's something we
> discussed on IRC but never formally I guess :-)

I've got Keep-Alive working.  I'll post the patches in a few hours when I
get home and have a real email client.

The Python BaseHTTPServer code supports Keep-Alive quite nicely but the
XML-RPC has an ugly bug where it always shutdowns the connection
explicitly after a POST.  After overriding the offending method, and
subclassing the RequestHandler to enabled HTTP/1.1 as the default
protocol, it appears to Just Work.

I'll do an xm-test run this afternoon and hopefully have a well-tested
patch (for keep-alive) by the evening.

>> This makes my patch a lot nicer though.  I just would make sure the
>> client uses Keep-Alive and then you get the same 1-time auth without
>> any of the SSH trickery.
> 
>   Is that just client side ?

I'm showing my ignorance a bit.  Defaulting to HTTP/1.1, Keep-Alive is
enabled by default.  I just have to cleanup the SSH transport now to
actually make use of it.

I don't think it's worth having the httpu/http protocols use Keep-Alive by
default but I'm sure we'd want to make use of it force https.

Regards,

Anthony Liguori

>> I'm investigating this right now.  I seem to recall the HTTP server in
>> python providing support for Keep-Alive...
> 
>   Okay, maybe I'm off base :-)
> 
>> > 
>> > As Ian says, stunnel/SSL is probably easier from the client's point
>> > of view (although I do like the easier SSH key management this patch
>> > allows).
>> 
>> There doesn't have to be one solution.  The only real code that's needed
>> here is xm serve which is not more than 100 lines.  The client code is
>> more of an example.  I see no reason why we couldn't support all of these
>> protocols (httpu, http, https, ssh).
> 
>   Agreed, those are layered features, they should not have to conflict.
> 
> Daniel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel