Bug 1027319

Summary:	Websocket mapping created by downloadable cartridge does not work
Product:	OpenShift Online	Reporter:	Michal Fojtik <mfojtik>
Component:	Containers	Assignee:	Mrunal Patel <mpatel>
Status:	CLOSED UPSTREAM	QA Contact:	libra bugs <libra-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.x	CC:	agoldste, rmillner, xtian
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-11 20:10:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michal Fojtik 2013-11-06 14:46:23 UTC

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.

Comment 1 Michal Fojtik 2013-11-06 16:24:25 UTC

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.

Comment 2 Andy Goldstein 2013-11-07 17:22:14 UTC

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

Comment 3 Rob Millner 2013-11-08 20:48:37 UTC

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.

Comment 4 Mrunal Patel 2013-11-11 20:10:22 UTC

https://trello.com/c/pFdPlpEo/184-allow-non-root-mappings-for-websocket-proxy