This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: asyncio sslproto do not shutdown ssl layer cleanly
Type: behavior Stage: resolved
Components: asyncio Versions: Python 3.11
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: Manjusaka, asvetlov, grzgrzgrz3, kumaraditya, legnaleurc, thehesiod, yselivanov
Priority: normal Keywords:

Created on 2017-06-18 22:08 by grzgrzgrz3, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 2270 closed grzgrzgrz3, 2017-06-18 22:12
Messages (9)
msg296295 - (view) Author: Grzegorz Grzywacz (grzgrzgrz3) * Date: 2017-06-18 22:08
Asyncio on shutdown do not send shutdown confirmation to the other side. _SSLPipe after doing unwrap is calling shutdown callback where transport    is closed and quit ssldata wont be sent.
msg296531 - (view) Author: Grzegorz Grzywacz (grzgrzgrz3) * Date: 2017-06-21 09:17
No one yet responded, maybe this is unclear. I will clarify what is going on, why i made this change, what we gain from this and why this is not ideal solution.

I will focus on ssl layer shutdown as this issue regards.

We have connection asyncio <-> nginx

Lets see first situation asyncio initiates shutdown:

1. ideal:

asyncio   ---------->   nginx
Ideal situation asyncio sending shutdown and nginx replies back. This is how it works before attached PR.

2. we can't relay on nginx

asyncio   ---------->   nginx

At this point everything looks great, but what will happen when nginx do not sent shutdown - we will wait forever.
We have this situation here #29406.

Attached PR "fix" this problem (note is not ideal fix, more like workaround):

3. with fix:

asyncio   ---------->   nginx
asyncio is sending shutdown ssl data to nginx but not waiting for nginx response, transport is closed anyway. I think ideal will
be to wait for certain amount of time for response like Nikolay in #29406 propose. This will allow to implement SSL downgrade to
plain text.

Second situation, nginx sent ssl eof.

1. before fix:
nginx     ---------->   asyncio
In this case we are receiving nginx shutdown and correctly process it but after that, shutdown callback will close the transport before
shutdown is sent back. Asyncio will try to send this data but fail due to closed transport. There is another issue should be not possible
to write to closed transport. We are getting false-positive result to write. I do not analyze this deeper,
maybe there is a reason to it.

2. after fix:
nginx     ---------->   asyncio

This is clean, shutdown callback in _SSLPipe is removed. We close transport in ssl protocol.

I think connections between _SSLPipe and ssl protocol has design problems, _SSLPipe should be, as name suggest, only a pipe.
Callback for handshake and shutdown feels wrong. Ssl protocol based on _SSLPipie mode and state can figure out when to call
connection_made or close transport.
msg309821 - (view) Author: Alexander Mohr (thehesiod) * Date: 2018-01-11 18:53
@grzgrzgrz3, does this resolve the issue in ? I'm guessing you based this PR on that issue. If so I'd like it merged ASAP as otherwise our prod services will be incompatible with all future python releases given the original "fix" was reverted.  Thanks!
msg309826 - (view) Author: Grzegorz Grzywacz (grzgrzgrz3) * Date: 2018-01-11 19:44
No, this PR originally fix similar but different issue. 

However it also fix issue29406 as a side effect.
msg317704 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2018-05-25 19:39
Is this issue resolved now, or do we need to work on this?
msg327745 - (view) Author: Wei-Cheng Pan (legnaleurc) * Date: 2018-10-15 11:49
The SSL connection still cannot close cleanly in 3.7.0.
It will keep throwing read error during shutdown, so shutdown callback will never be called.

I've been test this PR for a while, and at least it fixes my problem.

Hope this PR can be included in 3.7.1, or at least 3.7.2.
msg332364 - (view) Author: Manjusaka (Manjusaka) * Date: 2018-12-22 19:13

Agree with Wei-Cheng.

The leak still bothers me for times, and still bother for third-party like

Yury, I think it's worth working on it. Using uvloop should not be a good idea for some people.
msg414181 - (view) Author: Kumar Aditya (kumaraditya) * (Python triager) Date: 2022-02-28 07:48
Since is fixed now, this can be closed.
msg414187 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2022-02-28 11:36
Date User Action Args
2022-04-11 14:58:47adminsetgithub: 74883
2022-02-28 11:36:37asvetlovsetstatus: open -> closed
resolution: duplicate
messages: + msg414187

stage: resolved
2022-02-28 07:48:58kumaradityasetnosy: + kumaraditya

messages: + msg414181
versions: + Python 3.11, - Python 3.5, Python 3.6, Python 3.7
2018-12-22 19:13:50Manjusakasetnosy: + Manjusaka
messages: + msg332364
2018-10-15 11:49:15legnaleurcsetnosy: + legnaleurc
messages: + msg327745
2018-05-25 19:39:53yselivanovsetmessages: + msg317704
2018-02-05 10:59:38asvetlovsetnosy: + asvetlov
2018-01-11 19:44:22grzgrzgrz3setmessages: + msg309826
2018-01-11 18:53:28thehesiodsetmessages: + msg309821
2017-06-21 09:17:37grzgrzgrz3setmessages: + msg296531
2017-06-19 19:49:35thehesiodsetnosy: + thehesiod
2017-06-18 22:13:00grzgrzgrz3setpull_requests: + pull_request2320
2017-06-18 22:08:35grzgrzgrz3create