Ahh, I was looking at it from a socket.io protocol level and forgot to look
to balancing purely at the HTTP level. This works for the cases where we
have some control of the client application but still doesn't allow me to
proxy any generic app that conforms to the socket.io spec. I can use this
for now though.
Is there any chance in being able to extract and stick on a component of
the request path?
-Bryan
On Mon, Apr 22, 2013 at 3:06 PM, Ian Scott <isc...@chippath.com> wrote:
> On 04/22/2013 12:40 PM, Bryan Talbot wrote:
>
> So it looks like there's no way to properly support socket.io currently
> with haproxy without hacking the client. I've been doing that (duplicate
> the token in the query string or header) during testing but don't want to
> do it generally since I'm not always in control of client code.
>
> Actually it looks like the socket.io client preserves any query string
> given in the io.connect() call. So there's no hacking of socket.io code
> required.
>
> I just did a quick test of the example on the socket.io homepage, with
> the call io.connect('http://localhost:8888?foo=somethingrandom') and
> foo=bar got passed along both in the initial handshake and websocket
> connection:
> http://localhost:8888/socket.io/1/?foo=somethingrandom&t=1366667914255
>
> ws://localhost:8888/socket.io/1/websocket/zWrhX7gYKiBnFmoqwVsr?foo=somethingrandom
>
> So if you set an arbitrary query string parameter and stick on it with
> urlp, it should work, and with no payload sniffing. Unless I'm missing
> something.
>
> Ian
>
