Path rewrites for websockets not being handled correctly

We're using the JS library socket.io to dynamically update an AngularJS app which we're using Knox to proxy. The socket.io library supports a number of protocols, upgrading to websockets if possible.

What we're seeing is that the websocket connection fails to be established all the way through to the backend, apparently because the URL that socket.io happens to use, which consists of a number of path segments and query components, is truncated back to the base backend URL only.

Analysis of the code suggests - 

 
a) The existing unit test (WebsocketEchoTest) is hard-coded to test a backend URL that ends in /ws. This corresponds to a special case in the code for Zeppelin, so the other paths are never tested, and hence the unit test always passes.
b) createWebSocket passes only a path, so the query component could never be considered by getMatchedBackendURL
c)  getMatchedBackendURL doesn't seem to base its logic on the rewrite rules at all, in the case where the backend URL doesn't end in /ws it appends the remainder of the path to the backend (you can demonstrate this by altering the test case to remove the /ws from the backend URL and running the existing test - the rewrite rule is {**}/channels but the result is simply /channels).
d) Due to (a) this is a moot point, but the unit test doesn't check that the path was rewritten as expected, so it will pass regardless.
 
The current thinking is that if we address (b) to pass a concatenation of the path and query then it might work for cases like ours. We also need to address (c) which will affect anyone wanting to control rewrites, and addressing (a) and (d) would help in the longer term.
 
I've raised all of this together for now, we can split it out into multiple items if you'd prefer. 

See thread at https://mail-archives.apache.org/mod_mbox/knox-user/201806.mbox/%3CCAGB2t9ganh6eiNkzckSGbvU9GJKUHxpAPakivpGzmKzrFdWvUg%40mail.gmail.com%3E for the rest of the discussion on this.