On freebsd 8, using python 2.6.6, I've run into the bug already widely dealt with in these reports :
http://bugs.python.org/issue1380952
http://bugs.python.org/issue1153016

When using socket timeouts (eg. with socket.setdefaulttimeout()), whatever the timeout I use (eg. 10 seconds), I begin having random "SSLError: The read operation timed out" exceptions in my http calls, via urlopen or 3rd party libraries.

Here is an example of traceback ending:

...
  File "/usr/local/lib/python2.6/site-packages/ZSI-2.0-py2.6.egg/ZSI/client.py", line 349, in ReceiveRaw
    response = self.h.getresponse()
  File "/usr/local/lib/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/local/lib/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/local/lib/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/local/lib/python2.6/socket.py", line 427, in readline
    data = recv(1)
  File "/usr/local/lib/python2.6/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/usr/local/lib/python2.6/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out

I've checked the py2.6.6 sources, the patches described in previous reports are still applied (eg. SSL_pending() checks etc.), I have no idea of how so long socket timeouts might interfere with ssl operations...

I checked if issue1153016 has reappeared for me (Ubuntu, Python 2.6.6), but it hasn't. Both the urllib and the imaplib examples given there work fine for me. Or at least opening the connections works fine for me, which it didn't at the time of issue1153016.

But you say you have random errors, so maybe I need to exercise this more heavily. Can you attach a test script that can be used to make the bug appear?

> When using socket timeouts (eg. with socket.setdefaulttimeout()),
> whatever the timeout I use (eg. 10 seconds), I begin having random
> "SSLError: The read operation timed out" exceptions in my http calls,
> via urlopen or 3rd party libraries.

Well, this isn't a random error. It just signals that the timeout has expired. It's a pity that it raises SSLError rather than socket.timeout, though.

Or are you saying that the exception is raised too early? If so, it would be nice to have a way of reproducing.

The exception is raised too early, none of my calls takes more than 1-2 seconds and I've a default timeout set at 10s or more.

This occurs rather rarely, one or two times on some hundreds of calls. I'll make a little script to try to isolate the pb.

Humz on second thought you may be right, now I have some trouble reproducing the bugs (wich have been there since the beginning, though), so it may be that the webservice I call seldom takes 10+ seconds to answer (weird anyway).

I've placed timers in the codebase, the pb will eventually surface again.

Allright, it actually looks more like a pathological latency behaviour of my target platforms than a ssl bug... 
I was mislead by the heavy history of socket.settimeout(), sorry. >_<