xmlrpc, httplib and SSL

Roger Binns rogerb at rogerbinns.com
Mon Mar 29 07:45:24 CEST 2004

> You're shooting the messenger.  

Nothing personal intended :-)

> Every language whose objects can form cycles
> has to deal with the issue of reclaiming those cycles in the presence of
> destructors.  There is no automatically correct place to break such cycles.
> In those situations you have to either avoid cycles, decide how to reclaim
> them or get rid of __del__ in potentially cycle-forming objects.

I am not denying that is an issue.  The problem in this case is that because
there *could* be cycles, file/socket handles have to be manually closed.
The currently library goes out of its way to do so, together with a makefile
method (a kind of dup) to deal with ownership issues.  The problem is that
only raw UNIX file desciptors dup well.  SSL does not do so.

Additionally when layering over SSL, HTTP/1.1 persistent connections and
xmlrpclib, it all gets even more complicated.  The current library solves
that problem by not supporting SSL, not supporting persistent connections
and dealing with a maximum of one request/response in each loop, and always
closing afterwards.

The fix isn't simple.  Quite frankly I don't know what it is.  I did
do something that works for my project, but is not generally applicable.
If someone does want to solve this, I will provide moral support :-)


More information about the Python-list mailing list