Skip to main content

WebSocketConnect

hclient_core::unversioned

Trait WebSocketConnect 

Source 
pub trait WebSocketConnect {
    type WebSocket: WebSocket;

    // Required method
    fn websocket(
        &self,
        req: Request<()>,
    ) -> impl Future<Output = Result<Self::WebSocket, Error>>;
}
Expand description

A backend that can open a WebSocket.

Implemented either by a transport itself (hclient_fetch::Fetch, where the platform hands back messages) or by a connector over one (hclient_tungstenite::Tungstenite, where it hands back bytes and the framing is a crate of its own). Either way a WebSocket opened this way inherits everything the transport already knows: its runtime, its TLS configuration, its resolver.

Required Associated Types§

Source

type WebSocket: WebSocket

The open connection.

Required Methods§

Source

fn websocket( &self, req: Request<()>, ) -> impl Future<Output = Result<Self::WebSocket, Error>>

Open one.

§What req is for, and the duty it puts on the implementer

The URI is the only field with a required interpretation: ws:// and wss://, and http:///https:// read as the same two, since a caller who already holds an origin should not have to rewrite its scheme. Everything else the request carries — headers in particular — is a request to the implementer, and a backend that cannot send a header the request carries must fail rather than drop it. That is the rule hclient-wasi already follows for wasi:http’s request options, and it is what keeps this seam from becoming the place where an Authorization header silently does not go out. It is also the whole of the answer for a browser backend, which can send no headers at all beyond the subprotocol list.

The method and version are ignored: RFC 6455 §4.1 fixes both, and a backend is free to build the handshake it must build.

§Cancellation

Dropping this future before it completes stops the attempt, on exactly the terms Transport::execute states: no further bytes, nothing waited for, and the socket torn down rather than left running.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§