'Error during the websocket handshake occurred: HTTP code: 400' with TLS and nginx about tokio-tungstenite HOT 8 CLOSED

Most users don't want to mess with TLS at all, they just want to call connect_async("wss://foo.bar.com:443/socket") or something like that. We should not force them to deal with TCP and TLS internals. Yes, it may be a separate crate, but there is virtually no web without TLS in the XXI century. For those who does not want TLS here it may be just feature-gated.

from tokio-tungstenite.

tokio-tungstenite will not use TLS unless the stream which you pass to the client_async() is already a TLS stream. In other words, if you want to have a TLS you have to use tokio-tls crate in conjunction with tokio-core's TcpStream. Here is a good example how you can TcpStream and tokio-tls together: https://tokio.rs/docs/getting-started/tls/

from tokio-tungstenite.

Here is one more example: snapview/tungstenite-rs#1 (comment)

from tokio-tungstenite.

Thanks.

from tokio-tungstenite.

I used:

use native_tls::TlsConnector;
use tokio_tls::TlsConnectorExt;

let host = url.host_str().unwrap();

let tcp = TcpStream::connect(&url.to_socket_addrs().unwrap().next().unwrap(), &handle);

let tls_handshake = tcp.and_then(|socket| {
    TlsConnector::builder().unwrap().build().unwrap().connect_async(host, socket).map_err(|e| io::Error::new(io::ErrorKind::Other, e))
});

let client = tls_handshake.and_then(|stream| {

from tokio-tungstenite.

Yeah, something like this. And after TLS handshake is completed, you can start the WebSocket handshake by using tokio_tungstenite::client_async() on the stream.

from tokio-tungstenite.

I think it is to be supported in tokio-tungstenite as well. If the client just has an URL, it must be enough to connect.

from tokio-tungstenite.

It depends, we have to think on how to do it properly. Turning the Stream into a TlsStream when the URL contains wss may not be a desired behavior in several cases, especially if the user performs an upgrade of the existing connection which may already contain TLS stream inside.

We could solved the issue by having 2 client functions: client_async(url, stream) (like we do it now) and client_connect(url) (which does not take a stream parameter and so we create a stream ourselves), but this would add an additional dependency on TLS crate(s). In general having this function would not be a big benefit for those ones who are familiar with tokio and building services with it (our current stream-based implementation is easily composable with tokio).

Another important thing we have to keep in mind is that we have to remain consistent with the way how such things are handled in tokio-related crates, otherwise it will be confusing for tokio users. I've just had a short look at hyper, they have a tokio support and hyper itself does not depend on any of the TLS crates, in other words it does not handle https in a special way. HTTPS along with TLS dependency resides in a separate hyper-tls repository, which contains only the TLS connector for hyper in case if for some reasons a user wants to use it with hyper. Maybe this is the approach we have to follow.

So we have to consider those factors (note: in either case it would save ~3-5 LOC and for the most cases it does not give any significant advantages).

from tokio-tungstenite.