[
https://issues.apache.org/jira/browse/KNOX-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated KNOX-1361:
-------------------------------
Fix Version/s: (was: 1.2.0)
> Path rewrites for websockets not being handled correctly
> --------------------------------------------------------
>
> Key: KNOX-1361
> URL: https://issues.apache.org/jira/browse/KNOX-1361
> Project: Apache Knox
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: trsmith2
> Priority: Major
>
> 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.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
