Uploaded image for project: 'Apache Knox'
  1. Apache Knox
  2. KNOX-1361

Path rewrites for websockets not being handled correctly

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 1.0.0
    • 1.6.0
    • None

    Description

      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. 

       

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            smore Sandeep More
            trsmith2 trsmith2
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 20m
                20m

                Slack

                  Issue deployment