-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
Remove session on 4xx response from WebSocket handshake #25608
Conversation
@yfei-z Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@yfei-z Thank you for signing the Contributor License Agreement! |
@yfei-z downgrading from WebSocket to HTTP transports should work. Are you saying that it doesn't or that it doesn't in some specific scenario? Do you have a sample that demonstrates the issue? |
If the handshake failed because request missing some required header for example, the session still there wait for specified delay to be removed, in the meantime client downgrade request arrived, and the invalid session will be found by the same session ID. Here is the java client code to simulate the handshake failing and downgrade to xhr streaming: SockJsClient sockJsClient = new SockJsClient(new ArrayList<Transport>() {{
this.add(new WebSocketTransport(new JettyWebSocketClient(new WebSocketClient() {
@Override
public Future<Session> connect(Object websocket, URI toUri, ClientUpgradeRequest request) throws IOException {
return super.connect(websocket, toUri, request, new UpgradeListener() { // hacking web socket failing
@Override
public void onHandshakeRequest(UpgradeRequest request) {
Map<String, List<String>> headers = request.getHeaders();
headers.put("Upgrade", Collections.emptyList());
request.setHeaders(headers);
}
@Override
public void onHandshakeResponse(UpgradeResponse response) {
}
});
}
})));
this.add(new RestTemplateXhrTransport());
}}); |
Okay thanks for clarifying. I think we'll need to solve it differently since we can't change the contract. Probably check a) keep a boolean flag whether the session was just created (i.e. trying to connect) and b) whether the response status is in the 4xx range and if so remove the session. Would you like to update the PR accordingly? |
Please review |
Yes that looks better, thanks. |
I'm not sure if it's the best way to obtain the status code. |
The sockjs session will be removed after websocket handshake request failed, therefore the next downgrade session could be created.