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.
-Bryan On Fri, Apr 19, 2013 at 1:39 PM, Ian Scott <[email protected]> wrote: > On 04/19/2013 10:21 AM, Bryan Talbot wrote: > > I'm trying to find a way to get the two-http-request handshake that > socket.io uses to stick to the same server without using cookies for > persistence. Most of the guides I've found online all use cookies, but in > my case, at least some of the (non-browser) client apps don't support them. > > ... > > I think there are two problems which prevent me from doing this. The > first is that there is no pattern extraction method which can extract a > pattern from the url path. > > > I ran into a similar issue with sticking on requests from a similar > websocket/longpolling/etc library (nginx-push-stream-module) and solved it > by passing the channel ID in the querystring and sticking on urlp. It looks > like the socket.io protocol spec allows for user-defined query > components, but socket.io-client doesn't let you set them (unless I'm not > reading things properly). > > I agree that being able to extract from part of the URL path would be a > great feature. > > The second is that payload() extracts and stores a binary value and the > patterns that can extract values from the request (query string, header, > etc) all return a string. Can a string be used to match in a stick table > which stores binary values? > > From looking at the source, it'll let you do it. Whether it actually works > I'll let someone more knowledgeable answer. I could see one issue being > with null termination causing them to not match. > > http://git.1wt.eu/web?p=haproxy.git;a=blob;f=src/stick_table.c;h=3097e662fe1613178e6e2d561c101f2852acd85c;hb=HEAD#l591 > > Ian >
