socket.io doesn't work when "resource" option is specified in client

[WuTheFWasThat]

We're using haproxy to forward requests of the form

my.domain:443/special_token/socket.io/1/websocket/

To make this request from the browser, we do:

var socket = io.connect( 'http://my.domain:443', {
'resource': 'special_token',
});

However, we now get the following error.

Error during WebSocket handshake: location mismatch: ws://my.domain:443/special_token/socket.io/1/websocket/8835688411479694001 != ws://my.domain:443/socket.io/1/websocket/8835688411479694001

(which is at
https://github.com/ariya/phantomjs/blob/master/src/qt/src/3rdparty/webkit/Source/WebCore/websockets/WebSocketHandshake.cpp#L601)

I think the wrong location is expected when the "resource" option is specified. Is this right? Sorry in advance for any noobishness on my side

[JamesMGreene]

Offhand, this sounds like a problem with haproxy (or perhaps even socket.io) rather than PhantomJS. Can socket.io-client support the resource feature when using Hixie-76 draft protocol WebSockets?

cc: @guille

[arunkjn]

Same problem with me.
I am using node-proxy to proxy socket.io on various suburi's of my domain of the form-
mysite.com/Something/socket.io -> someip:port/socket.io
mysite.com/SomethingElse/socket.io -> someOtherIp:port/socket.io

I am using latest socket.io on server side as well as client side.
It works properly with the latest versions of Chrome/Firefox/Safari

I remember getting the same 'handshake error' when using old versions of chrome ~13/14
Is this an issue with the underlying webkit(possibly older)?
@JamesMGreene - It works great when I connect directly to the socket.io, but not when I connect through proxy.
@WuTheFWasThat Did you try removing that if check and rebuilding phantomJs? Did it work for you?

Update:
I rebuilt phantom with the above suggested changes and the websocket handshake is happening properly over a proxy.
Submitted a pullrequest for the same.
Test report can be found here. 4 tests are failing

[sodabrew]

@arunkjn Is it appropriate in all cases to remove that check? Could you explain why the check was wrong to be there in the first place?

[arunkjn]

@sodabrew I am not sure how this would affect other parts of the code, and what is the real purpose behind this check. Also I am not confident if this can be merged without review from others. All I remember is that the same error used to occur with old webkit (chrome/safari) browsers, at a time when Websockets protocol was still under draft. This was a security concern around cross origin requests and browsers did not entertain proxied request with a non matching path. (thinking of it as a forged request maybe)

EDIT: I read this from phantomJS website PhantomJS 2.x will eventually get a WebKit upgrade that has RFC 6455 websockets.
I think then this would no longer be required. So we would just have to wait for 2.x

[stale]

Due to our very limited maintenance capacity, we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed (see #15395 for more details). In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!