Red Hat Bugzilla – Bug 1027319
Websocket mapping created by downloadable cartridge does not work
Last modified: 2015-05-14 19:32:29 EDT
Description of problem: When adding a downloadable cartridge that define a 'websocket' mapping does expose the mapping however the websocket connection does not work properly (iow. the connection is not established). The cartridge use 'puma' ruby webserver to expose the websocket and there is a small Rack app that I tested locally and it is working. Version-Release number of selected component (if applicable): devenv Steps to Reproduce: 1. rhc app create ruby01 ruby-1.9 2. rhc add-cartridge https://raw.github.com/mfojtik/openshift-origin-cartridge-hamonitor/master/metadata/manifest.yml -a ruby01 3. Visit: http://xxx-xxx.dev.rhcloud.com/haproxy-monitor Actual results: The cartridge as it is now, should stard sending you the current time via websocket connection. If you check the HTTP communication in Firefox inspector, you will see the attempt to establish a new 'ws' connection: Response headers: Upgrade: websocket Sec-WebSocket-Accept: VwwqHdC88eD9m0fFNfgYYZJcIVY= Connection: Upgrade However, the connection is not established. Expected results: The connection to the websocket should be established succesfully, you should see the current time updating in browser. Additional info: The mappings are created succesfully, I can see 'ws' protocol in platform.log. Also there are no errors in the puma logs.
I spend some time investigating this issue and I discovered that the websocket request never reach the cartridge HTTP server (puma in this case). The node-web-proxy does not proxy the websocket request properly. In this case the: ws://ruby01-mfojtik.dev.rhcloud.com:8000/haproxy-monitor-socket is proxyfied to the application and not to the cartridge. Since the application does not provide the websocket interface, the websocket connection is closed. /var/log/node-web-proxy/websockets.log: 209.132.186.34 ruby01-mfojtik.dev.rhcloud.com - - [06/Nov/2013:11:17:14 -0500] "GET /haproxy-monitor-socket HTTP/1.1" 1011 0 "-" "Websocket RFC-6455/13" (3ms) - 209.132.186.34 ruby01-mfojtik.dev.rhcloud.com - - [06/Nov/2013:11:17:14 -0500] "GET /haproxy-monitor-socket HTTP/1.1" 1000 0 "-" "Websocket RFC-6455/13" (146ms) - You can easely reproduce this by using the steps from Description. I think the node-web-proxy will need to be a bit more smarter about deciding to what endpoint it is going to pass the websocket request. Assigning back to Node.
It looks like we currently only set up the node-web-proxy connection if the frontend path is / https://github.com/openshift/origin-server/blob/master/plugins/frontend/nodejs-websocket/lib/openshift/runtime/frontend/http/plugins/nodejs-websocket.rb#L49
The proxy code in the NodeJS websocket router doesn't know how to deal with multiple cartridges on different paths so the plugin class only passes that kind of URL down to the NodeJS routes file. It is a long standing issue to bring the NodeJS websocket router up to the same feature set as the Apache front-end. This bug should be converted into a Trello card and placed on the feature roadmap.
https://trello.com/c/pFdPlpEo/184-allow-non-root-mappings-for-websocket-proxy