Feature: Connection Timeout

[reneme]

This introduces a "connection timeout" to distinguish between an "overall timeout" and a timeout for the "network connection establishment" only. To keep the API backward compatible (and also to adhere to the "principle of least astonishment") the "connection timeout" is defaulted to whatever the "global timeout" is set to. Only if a user of the library specifically sets the "connection timeout" it is actually honoured.

http_client_config

The http_client_config now has a new set_connection_timeout() method along with the necessary internals. Furthermore it implements the "default to global timeout" mentioned above.

WinHTTP-based client

The adaption is simple, as WinHTTP provides WinHttpSetTimeouts that allows for individual timeouts for resolve, connect, send and receive. This just sets the "connection timeout" for resolve and connect and leaves the existing "global timeout" for send and receive.

ASIO-based client

The ASIO implementation is a bit more involved, as it handles timeouts with a custom wrapper class (timeout_timer) around a boost::asio::steady_timer. I extended the state-machine of this class to distinguish between connecting and communicating states (previously simply called started). Also, I refactored the "resetting" of the steady_timer to encapsulate the usage of the "connection timeout" or the "global timeout" depending on the timeout_timer's state.

I removed the m_timer.start() calls and added calls to m_timer.start_connecting() and m_timer.start_communicating() in strategic places. Unfortunately, those needed to go to slightly different locations as before. I would appreciate thorough a review here. More details on those locations are added via in-code review comments.

WinRT-based client

Unfortuantely, I'm not familiar with that implementation. Therefore, I didn't touch it. Help would be appreciated.

[reneme]

This call moved to the call site of the surrounding method (ssl_proxy_tunnel::start_proxy_connect()) i.e. asio_context::start_request(). This is the only location where ssl_proxy_tunnel::start_proxy_connect() is called if a proxy-tunnel is required. asio_context::start_request() also initiates the ordinary connection (without a proxy-tunnel). Therefore, I found it more consistent to move the call to start_connecting() there.

[reneme]

That is not needed anymore, as the conditional below should clearly distinguish the states of the timer:

a) The connection is reused (or an established proxy tunnel): In both cases the call to ctx->write_request() will eventually call m_timer.start_communicating(). Note that it is legal to call start_communicating() without a prior call to start_connecting() (e.g. when reusing an already established connection).

b) Otherwise, no connection is established yet, and a call to m_timer.start_connecting() is necessary. See just a few lines below...

[reneme]

This replaces the above-mentioned call inside ssl_proxy_tunnel::start_proxy_connect(). All calls to m_timer.start_connection() are now consistently placed inside asio_context::start_request().

[reneme]

This is inside the write_request() that starts sending the request to the server. Just before the respective async_write() we call m_timer.start_communicating() to switch the timeout_timer state from the "connection timeout" to the "global timeout".

Note that this method might also initiate a TLS handshake if required (see conditional above). In that case, the request is eventually sent inside handle_handshake() and not here.

[reneme]

As stated above, if a TLS handshake was required, this will now eventually send the request. As before, m_timer.start_communicating() switches the timeout_timer over to the "global timeout", just before sending the application payload data.