Closed Tockra closed 7 months ago
There is likely certain logic/processing in your app/tests that leads to such behavior - I can't tell more because I don't have a source code of a client/server. There is no special processing of authorization headers within tungstenite
or tokio-tungstenite
, so the behavior that you described cannot stem from our crate.
If you could provide a simple self-contained reproducible example of the client/server, we may try to help by checking if something is wrong with the way the crate is used, but I can't really judge about the client/server based on the provided snippet that just adds a couple of headers.
The only suggestion that I can give so far is that you typically don't need to generate Upgrade
, Sec-WebSocket-Version
and other headers. You can just call into_client_request()
on your URL and add the authentication header if that's what you need.
Okay thank you. I tried to build a small example which reproduces it, but I cant.
Maybe the reason for that is the authorization middleware I'm using: https://crates.io/crates/axum-keycloak-auth
Hi,
I'm trying to test my websocket implementation by using tokio_tungstenite. For that I build a small mapper function receiving a SocketAddr, endpoint and auth_token:
This connection seems not to work. My test blocks longer than 60 seconds here. If I place a wait (15 seconds) before the connect_async it works. I think the application does not provide the endpoints but the connect_async already tries to connect. But I can not explain why it blocks infinite. I don't want to place a hardcoded wait into my tests. Otherwise the test will burn time and I never can be sure if the waiting time is high enough on computers with low performance.
Some thoughts?