New submission from STINNER Victor:

While working on the 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.

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.

Currently, the user of the asyncio API cannot decide how to handle this failure.

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). Attached patch implements this idea.

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.

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?

----------
components: asyncio
files: accept_error.patch
keywords: patch
messages: 234856
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call protocol.connection_lost() when the creation of transport 
failed
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37884/accept_error.patch

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23333>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to