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

Websocket server returning 401; can't handle on client side #390

Closed
chenfisher opened this issue Jun 29, 2016 · 3 comments
Closed

Websocket server returning 401; can't handle on client side #390

chenfisher opened this issue Jun 29, 2016 · 3 comments
Assignees
Labels
Milestone

Comments

@chenfisher
Copy link

chenfisher commented Jun 29, 2016

I have a websocket server that returns 401 on the http handshake
I can't figure out how to get that information on the websocket client

Two things I can't figure out:

  1. Where can I get the http status code returned form the server (401 in this case)
    onClose is called but with irrelevant code (-1) which I saw in your code that it means "never connected"
  2. onError is called but for totally different reason. I get onError ssl == null
    why would the client library continue to try to decode the handshake, or something like that, when the socket wasn't upgraded (101)? why not just stop there? The ssl error is irrelevant here and is fired do to the fact that the server did not upgrade the socket

What I did to get the status code from the server was to subclass my own Draft, implement acceptHandshakeAsClient and copyInsance; this gave me access to the handshake response
When I see that the status code is 401 I return NOT_MATCHED
This is the only place I saw I can get the status code, but it makes me do ugly things like saving the status code in a variable to be used by onClose and onError which are then called (but with irrelevant data - code == -1 and error exception is ssl == null)

Thanks

@felippeduran
Copy link

felippeduran commented Oct 10, 2017

The pull request #567 fixes the exact issue mentioned by the item 1.

Regarding the item 2, I had the same issue when trying to handle a status code 503 during the HTTP handshake (mentioned on the pull request).

What seems to be a good solution is to make the Draft_6455 propagate these status codes to the websocket class and then expose it as a connection failure instead of CloseFrame.PROTOCOL_ERROR (or CloseFrame.NEVER_CONNECTED), even though the RFC6455 doesn't mention how to handle these errors (at least I couldn't find it).

Thanks!

@marci4 marci4 added the Bug label Oct 10, 2017
@marci4
Copy link
Collaborator

marci4 commented Oct 10, 2017

Hello @felippeduran,
I will be able to test this issue in two days probably .

Have you tested the issue against the current master branch code as well? Does this still cause issues?

Regarding the item 2, what do you think of an additional onError call with an exception indicating an invalid http status code?

Greetings
marci4

@marci4 marci4 self-assigned this Oct 10, 2017
@marci4
Copy link
Collaborator

marci4 commented Oct 12, 2017

Hello @felippeduran again,

I added a reason for the onClose call, if there was an error with the status code or status line.

Issue should be solved by that.

Greetings
marci4

@marci4 marci4 closed this as completed Oct 12, 2017
marci4 added a commit to marci4/Java-WebSocket-Dev that referenced this issue Oct 12, 2017
@marci4 marci4 added this to the Release 1.3.5 milestone Oct 13, 2017
marci4 added a commit to marci4/Java-WebSocket-Dev that referenced this issue Oct 13, 2017
marci4 added a commit that referenced this issue Oct 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants