[Python-ideas] PEP 3156: getting the socket or peer name from the transport

Thu Jan 24 20:37:25 CET 2013

Starting to seem like the transport could almost be an entry in the dictionary rather than owning it, kind of like environ['input'] in wsgi spec. Not that I'm necessarily recommending this, but it seems like the details may outlive the transports, could potentially include information the transport itself considered input, and may be a useful place to store details such as SSL details that might be shared. A lot of these details could be initialized when the transport was created, and many would be based on the whatever spawned it. For example, a transport spawned by an HTTPS server that accepted an incoming connection would inherit the SSL configuration, etc.
Shane Green 
www.umbrellacode.com
805-452-9666 | shane at umbrellacode.com
On Jan 24, 2013, at 11:14 AM, Ben Darnell <ben at bendarnell.com> wrote:
> On Tornado we basically do A (the IOStream's socket attribute was never really documented for public consumption but has become the de facto standard way to get this kind of information). As food for thought, consider extending this to include not just peer address but also SSL certificates. Tornado's SSL support uses the stdlib's ssl.SSLSocket, so the certificate is available from the socket object, but Twisted (I believe) uses pycrypto and things work differently there. To expose SSL certificates (and NPN, and other information that may or may not be there depending on SSL implementation) across both tornado- and twisted-based transports you'd need something like B or C. 
>> -Ben
>> On Thu, Jan 24, 2013 at 1:23 PM, Guido van Rossum <guido at python.org> wrote:
> A pragmatic question popped up: sometimes the protocol would like to
> know the name of the socket or its peer, i.e. call getsockname() or
> getpeername() on the underlying socket. (I can imagine wanting to log
> this, or do some kind of IP address blocking.)
>> What should the interface for this look like? I can think of several ways:
>> A) An API to return the underlying socket, if there is one. (In the
> case of a stack of transports and protocols there may not be one, so
> it may return None.) Downside is that it requires the transport to use
> sockets -- if it were to use some native Windows API there might not
> be a socket object even though there might be an IP connection with
> easily-accessible address and peer.
>> B) An API to get the address and peer address; e.g.
> transport.getsockname() and transport.getpeername(). These would call
> the corresponding call on the underlying socket, if there is one, or
> return None otherwise; IP transports that don't use sockets would be
> free to retrieve and return the requested information in a
> platform-specific way. Note that the address may take different forms;
> e.g. for AF_UNIX sockets it is a filename, so the protocol must be
> prepared for different formats.
>> C) Similar to (A) or (B), but putting the API in an abstract subclass
> of Transport (e.g. SocketTransport) so that a transport that doesn't
> have this doesn't need to implement dummy methods returning None -- it
> is now the protocol's responsibility to check for
> isinstance(transport, SocketTransport) before calling the method. I'm
> not so keen on this, Twisted has shown (IMO) that a deep hierarchy of
> interfaces or ABCs does not necessarily provide clarity.
>> Discussion?
>> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130124/9f73020f/attachment.html>