I was trying to use xmlrpclib.ServerProxy() with https and client
certificate validation (I know httplib doesn't do server certificate
validation yet). I found no way to pass on host/uri as a
(host,x509_dict) tuple as the connection methods support, so I came up
with this patch.

This should be considered for 2.6, not 2.5 (which is in feature freeze).

I'm hoping Bill Janssen can review this.

I would like to ask the submitter to review the code himself for
suitability in 2.6. The underlying API has been extended a lot, so it's
unlikely that this patch is still the best choice.

The only difference between xmlrpclib.py from trunk and 2.5.1 is in the
Marshaller class. Unrelated, as far as I can see.

Note that it seems that the intent of the original code was to support
this x509-dict all along:

$ grep -n x509 xmlrpclib.py.trunk
1224:    # Host may be a string, or a (host, x509-dict) tuple; if a string,
1228:    # @param host Host descriptor (URL or (URL, x509 info) tuple).
1230:    #     x509 info).  The header and x509 fields may be None.
1234:        x509 = {}
1236:            host, x509 = host
1251:        return host, extra_headers, x509
1262:        host, extra_headers, x509 = self.get_host_info(host)
1282:        host, extra_headers, x509 = self.get_host_info(host)
1362:        # host may be a string, or a (host, x509-dict) tuple
1364:        host, extra_headers, x509 = self.get_host_info(host)
1372:            return HTTPS(host, None, **(x509 or {}))

Basically just the ServerProxy constructor doesn't support it. One would
have to create a new class with a new constructor just because of it.
That's why I opened this ticket.

This patch also needs to include a patch to the documentation.

Martin: Do you agree with the discussion on the changes for 2.6?

Looking at this patch, I definitely agree with the need for
documentation.    And a test case which uses the SafeTransport class. 
But the patch itself also needs a bit more work.  (It uses httplib.HTTPS
underneath, and that needs more work, too.)  At a minimum, the caller
should be able to optionally specify somehow, either as a contructor
arg, or otherwise (a module-global variable, perhaps), a set of
certificate-authority root certs, which, if specified, would cause
client-side validation of the server's certificate.  I think this should
be added as an optional constructor arg to the HTTPS class.

Let's tentatively say this needs to go into 2.6.  Bill, if in the end
you decide against it, just reject the patch.

No test case.  No provision for client validation of server certificate.

I assume you wanted to close this too.