Bug 1027319 - Websocket mapping created by downloadable cartridge does not work
Websocket mapping created by downloadable cartridge does not work
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Mrunal Patel
libra bugs
Depends On:
  Show dependency treegraph
Reported: 2013-11-06 09:46 EST by Michal Fojtik
Modified: 2015-05-14 19:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-11 15:10:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Fojtik 2013-11-06 09:46:23 EST
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):


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 11:24:25 EST
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:


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: 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) - 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 12:22:14 EST
It looks like we currently only set up the node-web-proxy connection if the frontend path is /

Comment 3 Rob Millner 2013-11-08 15:48:37 EST
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.

Note You need to log in before you can comment on or make changes to this bug.