> Should there be an "SSL socket", which is > just like a regular socket? Does that really provide any additional > functionality to anyone? Most apps and classes that use TCP sockets > wrap the socket with socket._fileobject() to get "read" and "write", > anyway -- can't they just wrap it with socket.ssl instead?
The issue here is the pervasive influence of the socket model. Take the SocketServer module's BaseRequestHandler. It has a slot called "request" which is supposed to contain a socket, not a Raw I/O stream. Lots of other modules use that framework, including "pydoc", "SimpleHTTPServer", "BaseHTTPServer", "SimpleXMLRPCServer", and "CGIHTTPServer". I think a few appropriate modifications to BaseRequestHandler and StreamRequestHandler would do the trick here. More serious is "asyncore", which is all about sockets. The "dispatcher" class in that module is riddled with socket assumptions. And there's lots of code based on it. Looking at that, I come back to the idea that socket.ssl() should return an object which is a proper subtype of socket.socket. Probably with a few extra methods: read(), write() -- to support existing use of the SSLObject getpeercert() -- analogue to "getpeeraddr", but returns cert details shutdown() -- to close the SSL channel -- would return the underlying socket object Bill _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
