Giampaolo Rodola' <billiej...@users.sourceforge.net> added the comment:
> By the way, this "broken pipe" error could be due to the fact that the > FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps > the close() method should be overriden? ftplib.FTP_TLS class already calls unwrap() but only when closing a "secured" *data* connection. This is never done for the *control* connection as the examples shown in RFC-4217 do that only when dealing with the CCC command which is intended to switch the control connection back to clear text. Since ftplib.py does not implement the CCC command I would avoid to override its close() method. As for our test server we are currently shutting down the SSL layer for both connections (control and data) so this might be the cause of EPIPE. At this proposal I suggest to move the shutdown() call from SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and see what happens. If EPIPE keeps being raised then I would investigate on what EPIPE means in terms of OpenSSL itself. It might mean that the socket is supposed to be closed in which case it's perfectly legitimate. I'd have a few questions: > a workaround for the strange SSL_shutdown() error return, also > witnessed by LightHTTPd users (see URL in comments) What happens now? I mean... what do we get instead of socket.error: 0? > an auto-retry for SSLSocket.unwrap() in blocking mode Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to already do that for us? > I think the SSL_shutdown() issue should be checked on the OpenSSL > mailing-list. If socket.error: 0 comes from OpenSSL then yes. I was suspecting something like this. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8108> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
