requests treats urllib3's SSL handshake timeout as ReadTimeout

Expected Result

When connecting to a remote machine via SSL/TLS, and SSL handshake timeout happens, I expect to have SSLError or ConnectionError exception.

Actual Result

requests raises ReadTimeout

Reproduction Steps

I don’t know how to reproduce this, but I have a real stacktrace (most recent call first):

timeout: _ssl.c:704: The handshake operation timed out
  File "urllib3/connectionpool.py", line 346, in _make_request
    self._validate_conn(conn)
  File "urllib3/connectionpool.py", line 850, in _validate_conn
    conn.connect()
  File "urllib3/connection.py", line 326, in connect
    ssl_context=context)
  File "urllib3/util/ssl_.py", line 329, in ssl_wrap_socket
    return context.wrap_socket(sock, server_hostname=server_hostname)
  File "python3.5/ssl.py", line 385, in wrap_socket
    _context=self)
  File "python3.5/ssl.py", line 760, in __init__
    self.do_handshake()
  File "python3.5/ssl.py", line 996, in do_handshake
    self._sslobj.do_handshake()
  File "python3.5/ssl.py", line 641, in do_handshake
    self._sslobj.do_handshake()
ReadTimeoutError: HTTPSConnectionPool(host='somehost.com', port=443): Read timed out. (read timeout=5)
  File "requests/adapters.py", line 440, in send
    timeout=timeout
  File "urllib3/connectionpool.py", line 639, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "urllib3/util/retry.py", line 357, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "urllib3/packages/six.py", line 686, in reraise
    raise value
  File "urllib3/connectionpool.py", line 601, in urlopen
    chunked=chunked)
  File "urllib3/connectionpool.py", line 349, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=conn.timeout)
  File "urllib3/connectionpool.py", line 309, in _raise_timeout
    raise ReadTimeoutError(self, url, "Read timed out. (read timeout=%s)" % timeout_value)
ReadTimeout: HTTPSConnectionPool(host='somehost.com', port=443): Read timed out. (read timeout=5)
  File "wsa/external/soap.py", line 234, in call
    response = command(**params)
  File "zeep/client.py", line 45, in __call__
    self._op_name, args, kwargs)
  File "zeep/wsdl/bindings/soap.py", line 113, in send
    options['address'], envelope, http_headers)
  File "zeep/transports.py", line 95, in post_xml
    return self.post(address, message, headers)
  File "wsa/external/soap.py", line 75, in post
    return super(NonPersistentTransport, self).post(address, message, headers)
  File "zeep/transports.py", line 67, in post
    timeout=self.operation_timeout)
  File "requests/sessions.py", line 555, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "raven/breadcrumbs.py", line 297, in send
    resp = real_send(self, request, *args, **kwargs)
  File "requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "requests/adapters.py", line 521, in send
    raise ReadTimeout(e, request=request)

System Information

$ python -m requests.help

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.3"
  },
  "platform": {
    "release": "3.10.0-693.5.2.el7.x86_64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000105f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

$ openssl version

OpenSSL 1.0.2k-fips  26 Jan 2017

$ cat /etc/redhat-release
$ uname -spori

OS: CentOS Linux release 7.4.1708 (Core), Linux 3.10.0-693.5.2.el7.x86_64 x86_64 x86_64 GNU/Linux

[metheoryt]

@sigmavirus24 I’m sorry if I misled you with ConnectionError, I meant ConnectTimeout.

I think of this situation as of borderline case between connection timeout and read timeout. Intuition acts as a background for the left part, while technical nature is a background for the right part.

Indeed, TLS negotiation is a part of connection procedure. At this stage no business data is sent (even headers). There is no logical reason to treat this case as ReadTimeout, because ReadTimeout by design tell us that the request COULD BE received and processed by server, while ConnectTimeout tells that the request WAS NOT received and, therefore, wasn’t processed.

Another argument for ConnectTimeout is that message of this particular ReadTimeout contains waiting time for connection but not for response. (the exception sais (read timeout=5) while i was having 5 seconds for connection and 22 for response waiting).

[drice]

I am seeing this issue as well. If you use a different timeout value for connect timeout and read timeout. For instance if you pass in (10, 1000), you will see a read timeout after 10 seconds even though the connect timeout is 10 seconds. Observed in requests 2.19.1