Author geertj
Recipients alex, christian.heimes, dstufft, geertj, giampaolo.rodola, janssen, pitrou
Date 2014-10-05.22:21:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1412547717.94.0.664501598014.issue22559@psf.upfronthosting.co.za>
In-reply-to
Content
It seems that SSLSocket.close() doesn't actually close the socket, and that's why the server side read() blocks.

It's a bit of a mystery to me how socket.close(), which is called by SSLSocket to do the actual close, is supposed to work. I don't see any calls to _sock.close() in there..

If I add the following 3 lines to socket.py then it works (but there's a few unexpected EOF errors in return).

diff -r ae64614b66b7 Lib/socket.py
--- a/Lib/socket.py     Sat Oct 04 18:24:32 2014 -0400
+++ b/Lib/socket.py     Sun Oct 05 18:16:51 2014 -0400
@@ -192,6 +192,9 @@
     def close(self, _closedsocket=_closedsocket,
               _delegate_methods=_delegate_methods, setattr=setattr):
         # This function should not reference any globals. See issue #808164.
+        if hasattr(self._sock, '_dummy'):
+            return
+        self._sock.close()
         self._sock = _closedsocket()
         dummy = self._sock._dummy
         for method in _delegate_methods:

I'm probably overlooking something b/c I can't imagine socket.close() being a no-op.
History
Date User Action Args
2014-10-05 22:21:57geertjsetrecipients: + geertj, janssen, pitrou, giampaolo.rodola, christian.heimes, alex, dstufft
2014-10-05 22:21:57geertjsetmessageid: <1412547717.94.0.664501598014.issue22559@psf.upfronthosting.co.za>
2014-10-05 22:21:57geertjlinkissue22559 messages
2014-10-05 22:21:57geertjcreate