And if it helps, the stack trace as a result of this from Knox follows.
Can I match a url containing &transport=websocket in one of the query
parameters and map it through to a service defined as ws:// in the
topology? At the moment, as above, everything is sent to a http:// service,
maybe this is the crux of the problem?
2018-05-12 07:09:47,361 ERROR gateway.websockets
(ProxyWebSocketAdapter.java:cleanupOnError(171)) - Error:
org.eclipse.jetty.websocket.api.UpgradeException: Didn't switch protocols
2018-05-12 07:09:47,362 ERROR gateway.websockets
(ProxyWebSocketAdapter.java:onWebSocketConnect(105)) - Unable to connect to
websocket server: java.io.IOException: Connect failure
java.io.IOException: Connect failure
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.connect(ClientContainer.java:157)
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.connectToServer(ClientContainer.java:180)
at
org.apache.knox.gateway.websockets.ProxyWebSocketAdapter.onWebSocketConnect(ProxyWebSocketAdapter.java:97)
at
org.eclipse.jetty.websocket.common.events.JettyListenerEventDriver.onConnect(JettyListenerEventDriver.java:87)
at
org.eclipse.jetty.websocket.common.events.AbstractEventDriver.openSession(AbstractEventDriver.java:227)
at
org.eclipse.jetty.websocket.common.WebSocketSession.open(WebSocketSession.java:421)
at
org.eclipse.jetty.websocket.server.WebSocketServerConnection.onOpen(WebSocketServerConnection.java:72)
at
org.eclipse.jetty.io.AbstractEndPoint.upgrade(AbstractEndPoint.java:185)
at
org.eclipse.jetty.server.HttpConnection.completed(HttpConnection.java:345)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:436)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.eclipse.jetty.websocket.api.UpgradeException: Didn't switch
protocols
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.validateResponse(UpgradeConnection.java:314)
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.read(UpgradeConnection.java:241)
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.onFillable(UpgradeConnection.java:163)
... 4 more
2018-05-12 07:09:47,373 WARN websockets.ProxyWebSocketAdapter
(AbstractEventDriver.java:unhandled(245)) - Unhandled Error (closing
connection)
org.eclipse.jetty.io.RuntimeIOException: java.io.IOException: Connect
failure
at
org.apache.knox.gateway.websockets.ProxyWebSocketAdapter.onWebSocketConnect(ProxyWebSocketAdapter.java:106)
at
org.eclipse.jetty.websocket.common.events.JettyListenerEventDriver.onConnect(JettyListenerEventDriver.java:87)
at
org.eclipse.jetty.websocket.common.events.AbstractEventDriver.openSession(AbstractEventDriver.java:227)
at
org.eclipse.jetty.websocket.common.WebSocketSession.open(WebSocketSession.java:421)
at
org.eclipse.jetty.websocket.server.WebSocketServerConnection.onOpen(WebSocketServerConnection.java:72)
at
org.eclipse.jetty.io.AbstractEndPoint.upgrade(AbstractEndPoint.java:185)
at
org.eclipse.jetty.server.HttpConnection.completed(HttpConnection.java:345)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:436)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Connect failure
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.connect(ClientContainer.java:157)
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.connectToServer(ClientContainer.java:180)
at
org.apache.knox.gateway.websockets.ProxyWebSocketAdapter.onWebSocketConnect(ProxyWebSocketAdapter.java:97)
... 12 more
Caused by: org.eclipse.jetty.websocket.api.UpgradeException: Didn't switch
protocols
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.validateResponse(UpgradeConnection.java:314)
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.read(UpgradeConnection.java:241)
at
org.eclipse.jetty.websocket.client.io.UpgradeConnection.onFillable(UpgradeConnection.java:163)
... 4 more
On Fri, May 11, 2018 at 9:04 PM, T Smith <[email protected]> wrote:
> Sorry, the other question was version. I'm using 1.0.0.
>
> On Fri, May 11, 2018 at 9:03 PM, T Smith <[email protected]> wrote:
>
>> Hi Sandeep,
>>
>> Here's what's happening -
>>
>>
>> 1. Request URL:
>> http://34.244.121.78:8443/gateway/pnda/pndaconsole/socket.
>> io/?EIO=3&transport=polling&t=MDGlYhd
>>
>> <http://34.244.121.78:8443/gateway/pnda/pndaconsole/socket.io/?EIO=3&transport=polling&t=MDGlYhd>
>> 2. Request Method:
>> GET
>> 3. Status Code:
>> 200 OK
>>
>>
>> 1. Request URL:
>> ws://34.244.121.78:8443/gateway/pnda/pndaconsole/socket.io/?
>> EIO=3&transport=websocket&sid=n_JBdgXCw_sZL-Q5AAOW
>>
>> <http://34.244.121.78:8443/gateway/pnda/pndaconsole/socket.io/?EIO=3&transport=websocket&sid=n_JBdgXCw_sZL-Q5AAOW>
>> 2. Request Method:
>> GET
>> 3. Status Code:
>> 101 Switching Protocols
>>
>> So far, so good. But, the next couple of requests fail, with 400 or 500
>> range errors, and the gateway log complains about protocol errors. I can
>> supply these if you need them, I'm trying to be concise here to get the big
>> picture across.
>>
>> Looking at tcpdump, what's happening is that ws:// request is being
>> nerfed to a GET /, which on my backend happens to resolve to a nice front
>> page of HTML. Websockets obviously panics as this isn't what it expected,
>> and then the whole process repeats. On my backend, /socket.io is routed
>> to the socket endpoint, whereas / isn't. So, my theory is that if I can
>> somehow convince Knox to send out the ws:// request with the correct path
>> including /socket.io, it might work.
>>
>> At the moment my service/rewrite sections are very simple, I pick up
>> requests with socket.io and send them off to the backend.
>>
>> services.xml -
>>
>> <policies>
>> <policy role="webappsec"/>
>> <policy role="authentication" name="Anonymous"/>
>> <policy role="rewrite"/>
>> <policy role="authorization"/>
>> </policies>
>> <routes>
>> <route path="/pndaconsole">
>> </route>
>> <route path="/pndaconsole/**">
>> <rewrite apply="PNDACONSOLE/pndaconsole/outbound/app"
>> to="response.body"/>
>> </route>
>> </routes>
>>
>> rewrite.xml -
>>
>> <rule dir="IN" name="PNDACONSOLE/pndaconsole/inbound/root"
>> pattern="*://*:*/**/pndaconsole/">
>> <rewrite template="{$serviceUrl[PNDACONSOLE]}/"/>
>> </rule>
>> <rule dir="IN" name="PNDACONSOLE/pndaconsole/inbound/socket"
>> pattern="*://*:*/**/pndaconsole/socket.io/?{**}
>> <http://socket.io/?%7B**%7D>">
>> <rewrite template="{$serviceUrl[PNDACONSOLE]}/socket.io/?{**}
>> <http://socket.io/?%7B**%7D>"/>
>> </rule>
>> <rule dir="IN" name="PNDACONSOLE/pndaconsole/inbound/path"
>> pattern="*://*:*/**/pndaconsole/{**}">
>> <rewrite template="{$serviceUrl[PNDACONSOLE]}/{**}"/>
>> </rule>
>> (I've snipped the rest of the rules handling outbound rewrites as I don't
>> believe they're relevant, but let me know if you think otherwise)
>>
>> By all accounts it looks like it's *nearly* working, but I'm stumped on
>> where my /socket.io path is going. I was considering routing all
>> websockets stuff to a completely separate backend/port so that it would go
>> to the right place regardless of how it was rewritten, but that seems a bit
>> extreme and I was hoping to use this approach.
>>
>> My end to end is -
>>
>> client, an angularjs app --> knox --> nginx --> reverse proxied
>> websockets backend in nodejs
>> -->
>> flat files, being an angularjs app
>>
>> We don't have to use socket.io, I guess, but it is currently used
>> everywhere so I'd rather avoid swapping that out to get this working if
>> possible. It's a fairly common library.
>>
>> Cheers,
>>
>> /ailuropod4 <[email protected]>
>>
>>
>>
>> On Fri, May 11, 2018 at 8:18 PM, Sandeep Moré <[email protected]>
>> wrote:
>>
>>> Hello,
>>>
>>> I am not very familiar with socket.io apps, so you might have to fill
>>> me in about what you are trying to do.
>>> Looks like you are having issue rewriting Websocket url.
>>>
>>> What version of Knox are you using ?
>>> Knox 0.13.0 and up supports better URL rewriting, see KNOX-776
>>> <https://issues.apache.org/jira/browse/KNOX-776>, it also has some
>>> examples in the comments.
>>>
>>> What is the ws:// url you are trying to rewrite and the rules you are
>>> using ?
>>>
>>> Best,
>>> Sandeep
>>>
>>> On Fri, May 11, 2018 at 2:54 PM, T Smith <[email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm struggling to get a simple socket.io based application working
>>>> through Knox.
>>>>
>>>> I see websockets is supported, but the upgrade handshake seems to be
>>>> nerfed on the way out, specifically the /socket.io/? etc part simply
>>>> becomes /.
>>>>
>>>> I've tried lots of permutations - does anyone have a working example
>>>> they can point me towards? I've looked at the Zeppelin approach, but this
>>>> isn't quite the same thing (not socket.io).
>>>>
>>>> Any help appreciated!
>>>>
>>>> /ailuropod4 <[email protected]>
>>>>
>>>
>>>
>>
>
