2.8.0 release raise ConnectTimeout on not known url

[aarefiev22]

2.7.0 and 2.8.0 raises diff exception on not known url:

import requests
requests.get('http://fake')

2.8.0:
requests.exceptions.ConnectTimeout: HTTPConnectionPool(host='fake', port=80): Max retries exceeded with url: / (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7fac9c476110>: Failed to establish a new connection: [Errno -2] Name or service not known',))

2.7.0
requests.exceptions.ConnectionError: ('Connection aborted.', gaierror(-2, 'Name or service not known'))

[Lukasa]

Hmm, looks like urllib3 changed how it wrapped this exception. Let me see if I can find where this problem got introduced.

[Lukasa]

I suspect urllib3/urllib3#703 may have introduced a new exception type that urllib3 treats differently to socket.error.

[sigmavirus24]

@Lukasa if the OpenStack gate is indicative of anything, it's between 1.10.4 and 1.11

[Lukasa]

Looks to me like it was actually done in 1.12: NewConnectionError is a subclass of ConnectTimeoutError, whereas previously socket.error wouldn't have been.

[aarefiev22]

@Lukasa : yes looks like new NewConnectionError raised here: https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/connection.py#L142

[Lukasa]

Hmm, that's not right though: socket.error should have entered the retry block.

[Lukasa]

Regardless, the reason we think it's a ConnectTimeout is because the new exception is a child of ConnectTimeoutError. This is somewhat tricky to deal with: NewConnectionError is sometimes a timeout, but sometimes not.

[Lukasa]

I think from requests' perspective we just want to treat NewConnectionError as not a timeout, even though under the hood urllib3 will attempt to retry when it hits it.

[sigmavirus24]

Also cc'ing @shazow

[Lukasa]

Ok, a proposed bugfix is in #2812. There's some discussion in there about whether this fixes a permanent bug, or whether it's strictly a compatibility fix.

[shazow]

I suspect some of this might be platform/configuration-specific. I can't remember the exact details but I think there was a distinction between how OSX vs Linux (maybe Posix vs GNU?) systems behave when you make a new socket to a bad host. It might also have to do with the DNS settings. I vaguely remember in one case it would try to resolve it and hang around until timeout, in the other case it would quickly eliminate it as not resolvable and return a lower-level error.

I tried to normalize them under the same exception but not sure if I succeeded.