Spring Remove session on 4xx response from WebSocket handshake

The sockjs session will be removed after websocket handshake request failed, therefore the next downgrade session could be created.

Comment From: pivotal-issuemaster

@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.

Comment From: pivotal-issuemaster

@yfei-z Thank you for signing the Contributor License Agreement!

Comment From: rstoyanchev

@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?

Comment From: yfei-z

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());
}});

Comment From: rstoyanchev

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?