| msg24381 - (view) |
Author: pristine777 (pristine777) |
Date: 2005-02-27 19:41 |
| This bug was fixed in Python 2.3 but has resurfaced in Python 2.4 The original bug report can be found at: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=673797&group_id=5470 The method urlopen both in urllib and in urllib2 crashes if socket.setdefaulttimeout has been called. Below is a cut and paste when using the function in urllib. >>> import socket >>> socket.setdefaulttimeout(30.0) >>> import urllib >>> urllib.urlopen('https://members.tufts- health.com/memindex.html') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 180, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 374, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 794, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 675, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 642, in send self.connect() File "C:\Python24\lib\httplib.py", line 1069, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (2, 'The operation did not complete (read)') Thanks a ton! |
|
|
| msg24382 - (view) |
Author: Tarek Ziadé (tarek-ziade) |
Date: 2005-05-19 13:53 |
| Logged In: YES user_id=1163510 having same issue here, using imaplib thru ssl :/ >>> import socket >>> socket.setdefaulttimeout(10) >>> i = imaplib.IMAP4_SSL('mail.xxxx.com') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib/python2.4/imaplib.py", line 181, in __init__ self.welcome = self._get_response() File "/usr/lib/python2.4/imaplib.py", line 876, in _get_response resp = self._get_line() File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line line = self.readline() File "/usr/lib/python2.4/imaplib.py", line 1136, in readline char = self.sslobj.read(1) socket.sslerror: The read operation timed out so i can't get timeouts with ssl in imap :/ |
|
|
| msg24383 - (view) |
Author: Malte Helmert (maltehelmert) |
Date: 2005-06-20 15:12 |
| Logged In: YES user_id=1131890 Same problem here with Python 2.4 (#1, Jan 13 2005, 20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a minimal piece of code that fails (substitute a valid IMAP server accepting SSL connections): === start code snippet === import imaplib, socket socket.setdefaulttimeout(10.0) imaplib.IMAP4_SSL("imap.whatever.invalid") === end code snippet === This fails with the following traceback: === start traceback === Traceback (most recent call last): File "./imap_bug.py", line 3, in ? imaplib.IMAP4_SSL("imap.whatever.invalid") File "/usr/local/lib/python2.4/imaplib.py", line 1101, in __init__ IMAP4.__init__(self, host, port) File "/usr/local/lib/python2.4/imaplib.py", line 181, in __init__ self.welcome = self._get_response() File "/usr/local/lib/python2.4/imaplib.py", line 876, in _get_response resp = self._get_line() File "/usr/local/lib/python2.4/imaplib.py", line 969, in _get_line line = self.readline() File "/usr/local/lib/python2.4/imaplib.py", line 1135, in readline char = self.sslobj.read(1) socket.sslerror: The read operation timed out === end traceback === Remove the socket.setdefaulttimeout call and it works properly. The problem is not due to a slow network connection or overloaded server -- the script fails for all kinds of timeouts (1, 10, 100 seconds), but without a timeout the response is near-instantaneous. |
|
|
| msg24384 - (view) |
Author: Thomas Wouters (twouters) *  |
Date: 2006-05-25 11:24 |
| Logged In: YES user_id=34209 It seems this was specific to Windows (I was unable to reproduce it on any version of Python on my UNIX machines), but it also seems it's fixed in Python 2.5a2 (at least) -- I can reproduce it with Python 2.4 on Windows XP, but not in 2.5a2. I was unable to identify an obvious fix from the checkin messages, though (the only likely candidate is a checkin from before 2.4.0 was released, which claims to fix the same thing) so backporting to a possible new 2.4 release is not likely. Tentatively closing this as fixed. Please pipe up if it isn't fixed for you, in 2.5a2 or later releases. |
|
|
| msg24385 - (view) |
Author: Malte Helmert (maltehelmert) |
Date: 2006-05-25 12:43 |
| Logged In: YES user_id=1131890 As I noted in my comment, the problem occurred on Linux, too. However, it has disappeared in 2.5a2, thanks! |
|
|