Allow users to choose TLS backend (e.g., rustls) instead of hardcoding native-tls #504
Description
First off, thank you for this excellent library. I'm using it in a project that also leverages iroh for P2P networking, and I've encountered a dependency conflict related to the TLS backend that I believe could be resolved by adding feature flags.
The Problem
Currently, rust-socketio and its core dependency rust-engineio appear to hardcode or default to native-tls as the sole TLS backend for reqwest and tokio-tungstenite.
This creates two primary issues for users:
Dependency Conflicts in rustls-based Projects: My project requires all networking libraries to use the rustls backend for consistent, cross-platform behavior. However, because rust-socketio pulls in native-tls via its default-features, my project's final build ends up with both rustls and native-tls backends compiled into reqwest. On Windows, reqwest prioritizes native-tls (Schannel), which can behave differently from rustls, leading to unexpected TLS handshake failures (in my case, CERT_E_CN_NO_MATCH due to strict certificate chain validation). The iroh library, for instance, explicitly avoids this by forcing reqwest to use rustls-tls.
Limited Portability & Flexibility: For users who want to create pure rustls builds (e.g., for easier cross-compilation or to avoid platform-specific TLS libraries), the current setup makes this impossible without resorting to [patch] overrides in their own Cargo.toml.
When I temporarily removed Rust socketio, the error disappeared, and the connection success rate was 100%.
source: hyper_util::client::legacy::Error(Connect, Os { code: -2146762481, kind: Uncategorized, message: "The CN name of the certificate does not match the value passed." }) } } }