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

Fix WebSocket negotiation #4386

Merged
merged 3 commits into from
May 18, 2017
Merged

Conversation

RX14
Copy link
Contributor

@RX14 RX14 commented May 7, 2017

I have also added some specs (with HTTP and HTTPS) for this.


listen_port = port_chan.receive

ws2 = HTTP::WebSocket.new("ws://127.0.0.1:#{listen_port}")
Copy link
Contributor Author

@RX14 RX14 May 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider it a bug that I have to use ws2 to differentiate this variable from ws above, as that ws is introduced as a block parameter, which should introduce an entirely new variable. If someone from the core team agrees i'll make an issue for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it should not be required to use another variable. It seems that the on_message in the top is been triggered with the websocket in the bottom. between the two closures that covers ws and the spawn there might be something going on.

@RX14 RX14 mentioned this pull request May 7, 2017
Copy link
Member

@bcardiff bcardiff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides the two comments, these will be the first specs that runs an HTTP::Server. I am not sure if we were avoiding to do that for some reason: @ysbaddaden / @waj any opinion regarding that?


listen_port = port_chan.receive

ws2 = HTTP::WebSocket.new("ws://127.0.0.1:#{listen_port}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it should not be required to use another variable. It seems that the on_message in the top is been triggered with the websocket in the bottom. between the two closures that covers ws and the spawn there might be something going on.

ws.on_close do
http_ref.not_nil!.close
end
ws.run
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the server side there should be no ws.run

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah thanks, I forgot it did it for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@bcardiff bcardiff added kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:stdlib labels May 7, 2017
@bcardiff bcardiff added this to the Next milestone May 7, 2017
@RX14
Copy link
Contributor Author

RX14 commented May 10, 2017

I think that specs that run a HTTP::Server should be fine as long as we let the OS choose a port. There appear to be specs that run TCPServer, so I don't see that there would be any issue.

@bcardiff bcardiff merged commit 96169cc into crystal-lang:master May 18, 2017
@bcardiff
Copy link
Member

Thanks @RX14 . You were right regarding TCPServer and letting OS choose a port.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:stdlib
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants