Repository navigation
SSLProtocol violates app Protocol state machine #246
Description
Activity
changed the title [-]SSLProto violates Protocol state machine[/-] [+]SSLProtocol violates app Protocol state machine[/+] on Apr 16, 2019
Yes, it makes perfect sense to honor the CM -> ... -> CL state machine, I don't see a reason why not to. Thanks for the very detailed report and 2 proposals! I think the boolean value is the right way to go - WRAPPED, FLUSHING or SHUTDOWN may transit to UNWRAPPED before connection_lost() is called.
Yes! I'll create a PR for that.
Ahhh that slipped through the cracks, let me make one PR now.
Metadata
Metadata
Assignees
Labels
No labels
PYTHONASYNCIODEBUGin env?: YesSome instances of the
Protocolclass assumeconnection_lost()can only be called ifconnection_made()was called at some point. This does not appear to be explicitly guaranteed in the Python documentation, but the following comment strongly suggests that intent:https://github.com/python/cpython/blob/master/Lib/asyncio/protocols.py#L84
An error raised during the handshake phase triggers a transition back to
UNWRAPPED:https://github.com/MagicStack/uvloop/blob/master/uvloop/sslproto.pyx#L504
Following this code path further, we see that it will force close the transport, which triggers a call back to
SSLProtocol.connection_lost(). This is then forwarded onto the app'sProtocolinstance, even thoughconnection_made()was never called.Would it be appropriate to change the following guard to also exclude the
UNWRAPPEDstate?https://github.com/MagicStack/uvloop/blob/master/uvloop/sslproto.pyx#L337
Alternatively a boolean value could be used to track whether or not
connection_made()has ever been called.