Both MacOS Xcode 11 and Windows VS 2015 Builds Produce Same Issue with Socket.io 2.0+ Node Server
[2019-10-02 17:43:20] [connect] Successful connection [2019-10-02 17:43:20] [info] asio async_read_at_least error: system:10054 (An existing connection was forcibly closed by the remote host) [2019-10-02 17:43:20] [error] handle_read_http_response error: websocketpp.transport:2 (Underlying Transport Error) Connection failed. Reconnect for attempt:2
Anyone run into this yet?
I am having the same problem. Did you resolve this?
The problem only occurs for me with https:// connections. If I switch back to http:// everything is great. I have a feeling its related to OpenSSL. Maybe an expired ssl cert (mine isn't), or tls version issue, but something is preventing the SSL Handshake from occurring. I've tried building 30 different ways, CMAKE, NO CMAKE, INSTALL, VCPKG, VS BUILD. But always this same result. This is true for Release or Debug builds as well.
Try setting your connection to "http://socketio-chat-h9jt.herokuapp.com/" in the DEMO Windows Console App. This is hosted by Socket.IO and this CPP works great with it. But if I try to hit https:// SSL no good.

The little test rules out it being my node js server. Something on my client side does not like SSL https:// connections or wss://. I've tried multiple version of boost, asio, and OpenSSL. 2020-08-07 01:22:06] [connect] Successful connection [2020-08-07 01:22:06] [info] asio async_read_at_least error: system:10054 (An ex isting connection was forcibly closed by the remote host) [2020-08-07 01:22:06] [error] handle_read_http_response error: websocketpp.trans port:2 (Underlying Transport Error) [2020-08-07 01:22:11] [connect] Successful connection [2020-08-07 01:22:11] [info] asio async_read_at_least error: system:10054 (An ex isting connection was forcibly closed by the remote host) [2020-08-07 01:22:11] [error] handle_read_http_response error: websocketpp.trans port:2 (Underlying Transport Error)
Lastly, I just adjusted my webapp's TLS settings between 1.0, 1.1., 1.2. Changing the setting didn't change the error on https:// or wss://.