[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Antoine Pitrou report at bugs.python.org
Mon Mar 22 15:57:48 CET 2010


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch seems ok to me. This is how it was supposed to be in the
> first place if ssl.py behaved as expected with non blocking sockets.

Ok, patch applied.

In light of the recv() and recv_into() implementation change, I also
think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents
blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

See description in
http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html:

« SSL_MODE_AUTO_RETRY

        Never bother the application with retries if the transport is
        blocking. If a renegotiation take place during normal operation,
        a SSL_read(3) or SSL_write(3) would return with -1 and indicate
        the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
        environment applications must be prepared to handle incomplete
        read/write operations. In a blocking environment, applications
        are not always prepared to deal with read/write operations
        returning without success report. The flag SSL_MODE_AUTO_RETRY
        will cause read/write operations to only return after the
        handshake and successful completion. »

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________


More information about the Python-bugs-list mailing list