[Twisted-Python] TLSMemoryBIOProtocol _shutdownTLS what to do when not successfull
Hi, Here is this code in t.p.t.TLSMemoryBIOProtocol def _shutdownTLS(self): """ Initiate, or reply to, the shutdown handshake of the TLS layer. """ self._flushSendBIO() shutdownSuccess = self._tlsConnection.shutdown() self._flushSendBIO() if shutdownSuccess: # Both sides have shutdown, so we can start closing lower-level # transport. This will also happen if we haven't started # negotiation at all yet, in which case shutdown succeeds # immediately. self.transport.loseConnection()
From my tests using Curl as a client, self._tlsConnection.shutdown() always returns False.
----- I need to call self._tlsConnection.set_shutdown(SENT_SHUTDOWN | RECEIVED_SHUTDOWN) before calling shutdownSuccess = self._tlsConnection.shutdown() and then self._tlsConnection.shutdown() returns True, otherwise it returns False. def loseConnection(self): """ Send a TLS close alert and close the underlying connection. """ if self.disconnecting: return self.disconnecting = True if not self._writeBlockedOnRead and self._producer is None: from OpenSSL.SSL import RECEIVED_SHUTDOWN self._tlsConnection.set_shutdown(RECEIVED_SHUTDOWN) self._shutdownTLS() def _shutdownTLS(self): """ Initiate, or reply to, the shutdown handshake of the TLS layer. """ self._flushSendBIO() shutdownSuccess = self._tlsConnection.shutdown() self._flushSendBIO() if shutdownSuccess: # Both sides have shutdown, so we can start closing lower-level # transport. This will also happen if we haven't started # negotiation at all yet, in which case shutdown succeeds # immediately. self.transport.loseConnection() ---- How should the connection be handled when self._tlsConnection.shutdown() returns False?
From my tests, it looks like when shutdownSuccess is False, the self.transport.loseConnection() is never closed.
Many thanks, Adi -- Adi Roiban
On 03:47 pm, adi@roiban.ro wrote:
This isn't actually how this method is implemented in trunk@HEAD. I didn't search through its entire revision history to see if it was ever implemented this way, but I don't think it was. :) Can you produce this behavior with the latest Twisted release, unmodified?
Can you share a minimal server which demonstrates this? Also, an exact curl command line would be handy.
Just so everyone's clear, this isn't really a solution. It's roughly the same as not calling shutdown at all, just calling loseConnection.
How should the connection be handled when self._tlsConnection.shutdown() returns False?
The connection should wait for the peer to call shutdown as well and then close the connection. This is what the `ZeroReturnError` handling in `dataReceived` is for.
From my tests, it looks like when shutdownSuccess is False, the self.transport.loseConnection() is never closed.
That's right. But shutdownSuccess is sometimes expected to be true. Jean-Paul
On 03:47 pm, adi@roiban.ro wrote:
This isn't actually how this method is implemented in trunk@HEAD. I didn't search through its entire revision history to see if it was ever implemented this way, but I don't think it was. :) Can you produce this behavior with the latest Twisted release, unmodified?
Can you share a minimal server which demonstrates this? Also, an exact curl command line would be handy.
Just so everyone's clear, this isn't really a solution. It's roughly the same as not calling shutdown at all, just calling loseConnection.
How should the connection be handled when self._tlsConnection.shutdown() returns False?
The connection should wait for the peer to call shutdown as well and then close the connection. This is what the `ZeroReturnError` handling in `dataReceived` is for.
From my tests, it looks like when shutdownSuccess is False, the self.transport.loseConnection() is never closed.
That's right. But shutdownSuccess is sometimes expected to be true. Jean-Paul
participants (2)
-
Adi Roiban -
exarkun＠twistedmatrix.com