Author chrisb2
Recipients asvetlov, chrisb2, yselivanov
Date 2021-09-10.04:23:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1631247832.37.0.646410094935.issue45159@roundup.psfhosted.org>
In-reply-to
Content
An SSL connection created with loop.create_connection may have data_received called on its protocol after pause_reading has been called on the transport.

If an application has a protocol whose data_received method calls pause_reading on the transport then there is a chance that the data_received method will be called again before the application calls resume_reading on the transport.

That existing implementation of pause_reading at:
https://github.com/python/cpython/blob/62fa613f6a6e872723505ee9d56242c31a654a9d/Lib/asyncio/sslproto.py#L335

calls pause_reading on the underlying socket transport, which is correct.  However, there is a loop in the SSLProtocol's data_received method:
https://github.com/python/cpython/blob/62fa613f6a6e872723505ee9d56242c31a654a9d/Lib/asyncio/sslproto.py#L335

If the loop referenced above has more than one iteration then there is a chance that the application protocol's data_received method could call pause_reading on the transport.  If that happens on any iteration of the loop other than the last iteration, then the SSLProtocol's data_received method will call the application protocol's data_received method when it should not.

Stealing uvloop's asyncio ssl implementation would resolve this bug: https://bugs.python.org/issue44011
History
Date User Action Args
2021-09-10 04:23:52chrisb2setrecipients: + chrisb2, asvetlov, yselivanov
2021-09-10 04:23:52chrisb2setmessageid: <1631247832.37.0.646410094935.issue45159@roundup.psfhosted.org>
2021-09-10 04:23:52chrisb2linkissue45159 messages
2021-09-10 04:23:52chrisb2create