You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When connecting to a WebSocket I get the following error.
dart_sdk.js:92203 WebSocket connection to '...' failed: Error during WebSocket handshake: Incorrect 'Sec-WebSocket-Accept' header value
When I inspect the request and response headers in Chrome, it turns out that the value sent for "Sec-WebSocket-Key" is not what the server receives.
For example, for my last request according to Chrome DevTools the request header Sec-WebSocket-Key' was "tsP6wTNh8NMsyM0hUr+0FA==", but the header key actually received by the server was "p1b2ngpyCIq8d4OKrP/H+A==".
Looking at the traffic in Wireshark shows that stomp actually makes TWO requests. The first is received by the server. The second differs by including an Authorization header. This second request fails.
It looks like the stomp client expects a Sec-WebSocket-Accept generated from the second key, when the server generated one for the first key, thus making the Accept key invalid.
The text was updated successfully, but these errors were encountered:
nyvelius
changed the title
Possible issue with Sec-WebSocket-Key
Stomp makes TWO requests when using basic auth, causing Sec-WebSocket-Accept to be invalid
Nov 14, 2018
Perhaps the issue has something to do with Genymotion? It's been a while since I've used it and I don't recall how it handles networking. Might suggest posting on Stack Overflow though.
When connecting to a WebSocket I get the following error.
When I inspect the request and response headers in Chrome, it turns out that the value sent for "Sec-WebSocket-Key" is not what the server receives.
For example, for my last request according to Chrome DevTools the request header Sec-WebSocket-Key' was "tsP6wTNh8NMsyM0hUr+0FA==", but the header key actually received by the server was "p1b2ngpyCIq8d4OKrP/H+A==".
Looking at the traffic in Wireshark shows that stomp actually makes TWO requests. The first is received by the server. The second differs by including an Authorization header. This second request fails.
It looks like the stomp client expects a Sec-WebSocket-Accept generated from the second key, when the server generated one for the first key, thus making the Accept key invalid.
The text was updated successfully, but these errors were encountered: