Phil Pennock <python-...@spodhuis.org> added the comment: (Sorry for dropping this, lost available time)
I see your point. OTOH, use of SNI needs to be something that can be disabled and people need to be able to connect to host A while supplying host B, not necessarily using IP addresses for the specificity. Use- case example: someone has a service "www" hosted on ["www-1", "www-2", "www-3"]. They have an SSL certificate for "www" and they want to have a health-checker which probes for "working service, all certs valid and not about to expire". Unless s.connect() gains a keep_original_hostname=False option (?), this is hard to do. Then there's the principle of least surprise -- while it would be nice to get SNI working automatically for everyone, it's still plausible that amongst the various TLS servers out there are some which break horribly for SNI and upgrading Python shouldn't break the tools in use. So I tend towards favouring "make use of the newer, less well tested, protocol feature something that has to be explicitly enabled", even if it adds a line to boilerplate -- if SNI ever takes over the world (as Host: headers in HTTP have) then it can be defaulted on in future perhaps? In which case, if the default is to change, the API should be sorted now, so perhaps connect() should take an override_server_hostname=False flag, which will make it pass the connect() hostname parameter instead of self.server_hostname in the call to _ssl.sslwrap()? With checking for an IP address? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5639> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com