Occasional client crash
Closed this issue · 4 comments
I wasn't able to dig enough to find out the exact cause of the problem, but occasionally my client crashes with the following exception:
[Apr 17 2017 12:14:23.094 GMT+0430] WS connect error: Server responded with a non-101 status: 200
Response Headers Follow:
connection: keep-alive
date: Mon, 17 Apr 2017 07:44:23 GMT
transfer-encoding: chunked
[Apr 17 2017 12:14:23.103 GMT+0430] WS connect error: Server responded with a non-101 status: 200
Response Headers Follow:
connection: keep-alive
date: Mon, 17 Apr 2017 07:44:23 GMT
transfer-encoding: chunked
[Apr 17 2017 12:14:23.111 GMT+0430] Tunnel closed
_http_outgoing.js:354
throw new Error('"value" required in setHeader("' + name + '", value)');
^
Error: "value" required in setHeader("x-htunsess", value)
at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:354:11)
at new ClientRequest (_http_client.js:86:14)
at Object.exports.request (http.js:31:10)
at ClientConn.module.exports.ClientConn._recv (C:\Users\y\AppData\Roaming\npm\node_modules\wstunnel\lib\httptunnel\ClientConn.js:159:25)
at ClientRequest.<anonymous> (C:\Users\y\AppData\Roaming\npm\node_modules\wstunnel\lib\httptunnel\ClientConn.js:110:19)
at emitOne (events.js:96:13)
at ClientRequest.emit (events.js:188:7)
at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:474:21)
at HTTPParser.parserOnHeadersComplete (_http_common.js:99:23)
at Socket.socketOnData (_http_client.js:363:20)
It might be due to a proxy server or firewall messing with request, and I am not expecting to fix that, but it would be very helpful if client doesn't crash in such a situation and maybe just log an error and drop that connection but continue to work.
It appears you are using the undocumented "--http" option. This option turns off websocket and uses standard http request/response to establish a tunnel. It generally works but not as stable as websocket, usefully as a last resort workaround if you are unfortunate enough to be behind a really strict firewall. See if you can use websocket.
Not actually, I'm using it simply as how is been said on manual.
Here are my exact commands:
Server
wstunnel -s host:80 -t host:81
Client
wstunnel.cmd -t 88:host:81 ws://host:80
(Tunneling server's port 81 to local port 88)
If it helps here are subsequent requests which lead to crash:
Request 1
GET /?dst=1.2.3.4:81 HTTP/1.1
x-wstclient: 03DE0294-0480-05A5-B106-CF0700080009
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: /Xz+vjDSdSsXm+FGyU7Dew==
Host: 1.2.3.4
Sec-WebSocket-Protocol: tunnel-protocol
Response 1
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: FaMn//YCaoBcbOTfL7d6o6jlOQ0=
Sec-WebSocket-Protocol: tunnel-protocol
EndTime: 15:11:16.519
ReceivedBytes: 0
SentBytes: 216
Request 2
GET /?dst=1.2.3.4:81 HTTP/1.1
x-wstclient: 03DE0294-0480-05A5-B106-CF0700080009
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: rRpVrbV0pWzm8C02XBiL8w==
Host: 1.2.3.4
Sec-WebSocket-Protocol: tunnel-protocol
Response 2
HTTP/1.1 200 OK
Connection: keep-alive
Date: Tue, 18 Apr 2017 10:41:16 GMT
Content-Length: 3553
Request 3
GET /?dst=1.2.3.4:81 HTTP/1.1
x-wstclient: 03DE0294-0480-05A5-B106-CF0700080009
x-htundir: conn
Connection: keep-alive
Host: 1.2.3.4:80
Response 3
HTTP/1.1 200 OK
Connection: keep-alive
Date: Tue, 18 Apr 2017 10:41:16 GMT
Content-Length: 3553
I don't know much but as you said I can see that WebSocket headers are dropped after second request, but I haven't used --http option. Is there anything else I can do?
Ok so wstunnel is falling back to good old HTTP because the WebSocket request is being dropped by proxy or firewall between your client and server. If you are not using SSL (wss://host:port), try SSL (see the Nginx section in the readme).
Otherwise you can wrap client in a loop in a script as a workaround. I see that you've forked, hope you can have this sorted out. I am a bit busy and haven't touched CoffeeScript in a long while.