Hi, While working on the Python issue #23243 "asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed" (*), I saw that SelectorEventLoop._accept_connection() currently ignores errors on the creation of a transport.
(*) http://bugs.python.org/issue23243 When a server gets an incoming connection: it calls sock.accept(), creates a protocol, and then create the transport. It doesn't wait until the connection_made() of the protocol is called (until the transport was successfully created). For example, for a SSL server, the client may decide to close the connection because it doesn't trust the server certificate. In this case, the SSL handshake fails at server side, before connection_made() was called on the protocol. Currently, the user of the asyncio API cannot decide how to handle this failure. No protocol method is called. The transport and the protocol are silently destroyed, that's all. I propose to call the connection_lost() method of the protocol with the exception, even if the connection_made() method of the protocol was not called (and will never be called). It's a change in the undocumented "state machine" of protocols. Before, it was not possible to switch directly to connection_lost(): there is even an assertion which ensures that it never occurs in some unit tests. Examples: A server may log the connection failure, blacklist temporarely the client IP, etc. Problem: Since the protocol doesn't know the transport yet, it doesn't have access to the socket, and so cannot retrieve the IP address of the client. Maybe a new method should be added to protocols to handle this case? How do other event loops (Twisted, eventlet, Tornado, etc.) handle failures on incoming connection? I opened the following issue with a patch: http://bugs.python.org/issue23333 Victor
