Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom behavior for some handshake error cases #443

Open
PragmaTwice opened this issue Sep 6, 2024 · 4 comments · May be fixed by #444
Open

Support custom behavior for some handshake error cases #443

PragmaTwice opened this issue Sep 6, 2024 · 4 comments · May be fixed by #444

Comments

@PragmaTwice
Copy link

I found that currently the server side of tungstenite will directly drop the connection when encountering some handshake failures (the stream is moved into accept() so it will be dropped when an error occurs).

However I have a requirement to return a valid http response when some websocket related headers are missing (such as the connection upgrade header). Currently tungstenite seems unable to do this.

I wonder if some new accept functions can be added to tungstenite to support this?

@agalakhov
Copy link
Member

In fact, Tungstenite is able to do this without any changes. The clue is the stream itself. It should be just Read + White, and Tungstenite doesn't care about implementation details. Use a wrapper around some kind of stream reference (Arc?) which is safe to drop while keeping the original.

We could let Tungstenite return the failed stream inside of HandshakeError::Failure, but it would be a breaking change.

@PragmaTwice
Copy link
Author

PragmaTwice commented Sep 6, 2024

Ahh thank you, I can get your point.

It is a good idea to have something like WebSocketStream<SomeArcStreamWrapper<S>>, but to avoid a more compilcated type and also some runtime overhead, I'm wondering if I can convert it back into WebSocketStream<S> after a successful handshake. 🤔

@agalakhov
Copy link
Member

It is possible but quite fragile. There is from_raw_socket() so that you can construct WebSocketStream again. But it should be done immediately after doing handshake. It will break if there is some ongoing WebSocket traffic.

Alternatively you can perform the handshake by using MidHandshake directly. There is some freedom of specifying handshake results.

Probably we should add a impl From<WebSocket<Q>> for WebSocket<S> where S: From<Q> to do it safely.

@PragmaTwice
Copy link
Author

Thank you for your help! I have a new idea to maintain the current API and behavior while also allowing for handling invalid requests.

Let me create a pull request to provide more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants