Hide Forgot
Description of problem: tried to set up a simple webapplication which uses websockets written in go. The problem is that the websocket-connection isn't routed down to the webapplication and the connection closes immediately althought port 8000 is used. Version-Release number of selected component (if applicable): How reproducible: Create a new app using DIY cartridge and clone the following repo https://github.com/ioboi/websocket-openshift For testing use http://www.websocket.org/echo.html with "ws://wsdemo-ioboi.rhcloud.com:8000/" as url. A request doesn't get routed down to the application. Steps to Reproduce: 1. Create a new app using DIY cartridge 2. Clone the following repo https://github.com/ioboi/websocket-openshift 3. use http://www.websocket.org/echo.html with "ws://wsdemo-ioboi.rhcloud.com:8000/" as url. Actual results: A request doesn't get routed down to the application. Expected results: Should echo the request using websocket Additional info: Raised this in the openshift forum and got the reply to raise a defect https://www.openshift.com/forums/openshift/websockets-in-golang
Golang is not a core supported cartridge - we haven't mapped the WS proxy port yet. It may be a bit before I can get back around to this - in the meantime, I would accept a pull request for the cartridge manifest (https://github.com/smarterclayton/openshift-go-cart) to add WS support.
Created attachment 844745 [details] testcase: diy application this source will establish a simple websocket listener for port 8000, that is just an echo server.
Created attachment 844746 [details] testcase: ws:// echo test client using this app against the diy, you can test it locally to see it work, or against a public echo server. But when you test against a golang running cartridge, the hello message makes it in to the app, but the response does not make it back from the app. supervisor.log shows a playload.websocket: [object Object], and websockets.log shows that lines for the request: 66.187.233.202 ws-hurr.dev.rhcloud.com - - [02/Jan/2014:15:57:13 -0500] "GET / HTTP/1.1" 1011 0 "-" "Websocket RFC-6455/13" (2ms) - 66.187.233.202 ws-hurr.dev.rhcloud.com - - [02/Jan/2014:15:57:13 -0500] "GET / HTTP/1.1" 1000 0 "-" "Websocket RFC-6455/13" (13ms) - For further comparison, I will show two TCP streams. The first is running the web.go source on localhost, and the client.go against it (this fully works): -------------------------- GET /echo HTTP/1.1 Host: localhost:7777 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: cpfsyjW6fJ6mPH2E9XuPjw== Origin: http://localhost/ Sec-WebSocket-Version: 13 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: +t1Aiyh3QvOgcLVom16SVYKT/AU= hello, world! -------------------------- Now, I'll show the TCP stream, of this same web.go running on the golang cart, and the client.go run against it (this does not fully work): -------------------------- GET / HTTP/1.1 Host: ws-hurr.dev.rhcloud.com:8000 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: 63UPszRfYPWeOzGQY+jsNA== Origin: http://localhost/ Sec-WebSocket-Version: 13 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: ELSyYgO3qhh5JciMFAhyO63/kK8= ...V%..3I..z...$I...... --------------------------
I have created another DIY application with golang and used another websocket library called gorilla websocket (github.com/gorilla/websocket) and it is working fine. Application is hosted here : basic-mgrid.rhcloud.com Websocket connection is : ws://basic-mgrid.rhcloud.com:8000/sock Attaching the repo : basic.zip ( with openshift build scripts )
Created attachment 853036 [details] websocket working sample working sample
(In reply to Jijesh from comment #5) > Created attachment 853036 [details] > websocket working sample > > working sample Thanks for this sample. It's good to see that it works for a page loaded. I also tried your source in a "golang" cartridge, just changing the IP and PORT env variables, it also works just fine. I'm not convinced that it is completely sane though. We are expecting to give close attention to this codeline soon. I'm going to close this bug, as it appears to be largely a non-issue. Re-open if needed.