Reject connections before accepting them

[UkoeHB]

Currently you can only reject a connection after the websockets backend has accepted the connection. This means clients will always see 'connected' -> 'disconnected' events even if their connection request was rejected by your custom ServerExt.

There should be an additional step in the connection-acceptance protocol for pre-validating requests before the websockets backend can accept the connection.

It should be possible to move that step into the axum Upgrade::from_request() method and tungstenite Acceptor .. callback closure, although it's not clear the optimal/correct approach since server actors are async from their servers (there is a risk of introducing race conditions between pre-validating requests and registering connections in the ServerExt, e.g. if you reject duplicate connections).

[gbaranski]

In Axum there's a way - take a look at this example:

ezsockets/examples/chat-server-axum/src/main.rs

Lines 150 to 158 in 52c4b78

	let kick_me = query.get("kick_me");
	let kick_me = kick_me.map(|s| s.as_str());
	if matches!(kick_me, Some("Yes")) {
	return (
	axum::http::StatusCode::BAD_REQUEST,
	"we won't accept you because of kick_me query parameter",
	)
	.into_response();
	}

You can do some work before calling ezsocket.on_upgrade(server).

[UkoeHB]

It's good to know this can be solved in Axum. The tungstenite integration does not have a solution right now, so I am reopening to track that issue.

[gbaranski]

Yes that's true.
I think ezsockets had this feature in one of its prior version, not sure though.
We can implement this feature, but I'd prefer to make it exclusive to tungstenite runtime, so that it doesn't affect axum and doesn't make two ways to do rejection before accept.