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.

Author janssen
Recipients Arfrever, flox, giampaolo.rodola, janssen, pitrou, vstinner
Date 2010-03-15.00:11:27
SpamBayes Score 1.9659713e-10
Marked as misclassified No
Message-id <1268611889.51.0.61208135897.issue8108@psf.upfronthosting.co.za>
In-reply-to
Content
>> Depends on what we want.  It just suppresses information that's now
>> available.  What we'd really like is for the caller to recognize that
>> close() can fail, and should be re-tried if it does.  That requires
>> that we signal the error back up and out of the ssl module.  It seems
>> to me that any non-blocking code should recognize this and respect it.

> Well, first, it will break code which used to work perfectly well (as > the failing tests show). That OpenSSL decided to break compatibility
> in what looks like a minor bugfix release (0.9.8m) doesn't mean we
> should propagate the breakage.

I admit to being powerfully swayed by this argument.  Of course, you could also say that it exposes bugs in code which hasn't been tested enough.  Again, look at where this stack trace is coming from.  It's a default error handler in code that was written 10 years ago.  Perhaps that code needs more than just a default error handler; perhaps the handler in FTP_TLS should be more sophisticated.

> Second, I'm not an SSL expert, but it's not obvious to me that the
> application should have to ensure a "complete shutdown" before
> closing the socket. Often, stateful applicative protocols close
> their "session" anyway (*) before shutting down the transport layer,
> so I don't see what this additional precaution can buy
> (apart from code complication).

What it buys is the ability for careful code to properly shut down an SSL session when using non-blocking sockets.  If we apply the fix, we deny that, and I'm sure someone will immediately file a bug about it :-).
History
Date User Action Args
2010-03-15 00:11:29janssensetrecipients: + janssen, pitrou, vstinner, giampaolo.rodola, Arfrever, flox
2010-03-15 00:11:29janssensetmessageid: <1268611889.51.0.61208135897.issue8108@psf.upfronthosting.co.za>
2010-03-15 00:11:28janssenlinkissue8108 messages
2010-03-15 00:11:27janssencreate