[issue16763] test_ssl with connect_ex don't handle unreachable server correctly

2016-09-08 Thread Christian Heimes

Christian Heimes added the comment:

It's probably out of date :)

Please reopen if you still see this issue.

--
nosy: +christian.heimes
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16763] test_ssl with connect_ex don't handle unreachable server correctly

2014-06-30 Thread Mark Lawrence

Mark Lawrence added the comment:

Does the backport mentioned in msg178404 still need doing, can this be closed 
as out of date or won't fix or what?

--
nosy: +BreamoreBoy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16763
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16763] test_ssl with connect_ex don't handle unreachable server correctly

2013-03-03 Thread Ezio Melotti

Ezio Melotti added the comment:

Is this still an issue?

--
nosy: +ezio.melotti

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16763
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16763] test_ssl with connect_ex don't handle unreachable server correctly

2012-12-28 Thread Antoine Pitrou

Antoine Pitrou added the comment:

 support.transient doesn't help here since no exception is raised

An exception can still be raised in do_handshake(), which is called when the 
connection succeeds. But, yes, it's otherwise useless.

 Note that I'm not sure that connect_ex returning None is normal in the 
 first place

It is not. The 2.7 implementation currently calls socket.connect() and catches 
socket errors, while the 3.2 implementation directly calls socket.connect_ex(). 
This means the 2.7 implementation will unwillingly catch name resolution 
errors, and other issues:

 socket.socket().connect_ex((svnn.python.org, 443))
Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/antoine/cpython/27/Lib/socket.py, line 224, in meth
return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -5] No address associated with hostname
 ssl.wrap_socket(socket.socket()).connect_ex((svnn.python.org, 443))
-5

I will backport the 3.2 implementation of connect_ex() in order to fix this 
inconsistency. Unfortunately there is no easy way to test for it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16763
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16763] test_ssl with connect_ex don't handle unreachable server correctly

2012-12-24 Thread Charles-François Natali

New submission from Charles-François Natali:

test_ssl tests calling connect_ex don't handle unreachable servers properly:

test_ssl
Resource 'svn.python.org' is not available
Resource 'svn.python.org' is not available
test test_ssl failed -- Traceback (most recent call last):
  File /srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_ssl.py, 
line 246, in test_connect_ex
self.assertEqual(0, s.connect_ex((svn.python.org, 443)))
AssertionError: 0 != None


support.transient doesn't help here since no exception is raised.
Note that I'm not sure that connect_ex returning None is normal in the first 
place...

There's a related failure on OpenBSD/NetBSD  buildbots:

test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok

==
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/3.x.snakebite-openbsd51-amd64-1/build/Lib/test/test_ssl.py,
 line 685, in test_non_blocking_connect_ex
select.select([], [s], [], 5.0)
OSError: [Errno 22] Invalid argument


I guess that connect() can't succeed because of an unreachable host/connection 
refused, and the subsequent select() fails with EINVAL. This is most likely a 
kernel bug, select should report the socket as ready for write (one could then 
use getsockopt() to find the actual error).

--
components: Tests
messages: 178051
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl with connect_ex don't handle unreachable server correctly
type: behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16763
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com