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

Add callback to obtain handshake response as client in case of handshake failure. #238

Closed
wants to merge 6 commits into from

Conversation

cahlbin
Copy link

@cahlbin cahlbin commented Feb 3, 2014

This provides a listener callback to obtain the server's handshake response in case it was rejected with a HTTP status code != 101.

E.g. if the server rejects the WebSocket upgrade request by issuing a
HTTP response with 503 status code, then this HTTP response data can be
obtained via
WebSocketListener.onWebsocketHandshakeReceivedAsClientFailed(WebSocket,
ClientHandshake, ServerHandshake).

If there already is any other way of obtaining the server's response including http status code, please enlighten me :) Thanks / Christoffer

ddrscott and others added 6 commits November 21, 2013 09:46
- `writeThread = new Thread( this );` caused a circular reference so WebSocketClient and writeThread was never garbage collected.

- use 2 thread instance variables instead starting writeThread as a reader, then reassigning it as a writer in it's run method.
handshake failure.

E.g. if the server rejects the WebSocket upgrade request by issuing a
HTTP response with 503 status code, then this HTTP response data can be
obtained via
WebSocketListener.onWebsocketHandshakeReceivedAsClientFailed(WebSocket,
ClientHandshake, ServerHandshake)
Made WebSocketImpl.role field final.
Reworked private constructors and removed logic that re-used
client constructor in the server constructor, only to later re-assign
the role field.

Made constructors private, to enforce use of factory methods which
indicate Role by method name, to avoid relying on whether the second
argument is a single Draft, or a List<Draft>.
Use WebSocketImpl.getRole to avoid NullPointerException if draft has not
been assigned yet (i.e. WebSocketImpl.getDraft() returns null).

With this NullPointerException fixed, the code path through
closeConnection will be taken and an attempt to call removeConnection is
made. At that point, the connection will still be in state
ReadyState.NOT_YET_CONNETED, and will never have been added to the
connections collection. The appropriate action is to only attempt to
remove connections from server connection collection if it has
previously been added (i.e. reached ReadyState.OPEN).
@threat threat added the Bug label Jun 18, 2015
@marci4
Copy link
Collaborator

marci4 commented Oct 12, 2017

This issue is solved with #572

@marci4 marci4 closed this Oct 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants