Hi, Use haproxy 1.5-dev branch and stick tables. In your backend, just add the few line below: stick-table type string len 32 size 10K stick store-response set-cookie(YOURCOOKIENAME) stick on url_param(YOURPARAMNAME)
You could combine this with a few ACL to match either the Cookie header or the URL param, depending which one is present. I recommand using with "peer" keyword to get multiple haproxy to sync their tables. So in case of reload of haproxy or in case of lb failure, you could keep on redirecting users to the same backend. cheers On Mon, Mar 19, 2012 at 9:02 AM, Kamil Gorlo <[email protected]> wrote: > Hi Willy, > > On Sat, Mar 17, 2012 at 8:58 AM, Willy Tarreau <[email protected]> wrote: >> Hi Kamil, >> >> On Thu, Mar 15, 2012 at 10:17:21AM +0100, Kamil Gorlo wrote: >>> Hi guys, >>> >>> I want to use HAproxy as a LB to my HTTP API, but I want to balance >>> requests based on some route_id provided either in cookie or in URI >>> (flash apps cannot set headers in requests). It looks that only >>> appsession supports reading URI,. Is there any way to do this with >>> cookie option? Or how hard will it be to implement this, eventually? >> >> Could you please explain the complete workflow, who sets the initial >> cookie and how, then how it is presented by flash requests ? Maybe >> there are already solutions to this, maybe this needs some development >> but it's hard to tell what has to be done without knowing the exact >> steps. > > Ok, sure. > > To use our API you need to create session on server. You call /signin > and then backend sets the session cookie - it's highly preferred (for > some crucial features to work) that from now on all requests should go > to the same backend (just for backward compatibility (Nginx) I have > separate cookie for routing - this cookie might by set by LB or > backend, for now it is set by LB when client make request without > any). Some clients can easily pass cookies in headers, but not Flash. > > Flow with Flash is like this: > > Java script initializes session, make some requests in this session, > then Flash must make other requests (file upload) and use the same > session from browser - so JS pass session_id and route_id to Flash > application and later on this parameters are passed in URL (since > there is no way to send cookies from Flash when uploading file with > POST - AFAIK). > >>> I can't use appsession since as far as I understand it only work if I >>> have one process - in my environment this is not acceptable (I will >>> have multiple LB's to get high-availability and scalability - HAproxy >>> will be paired with stud to terminate SSL and this will probably need >>> more than two machines). >> >> Well, it could probably be cheaper to have only stud on some machines >> and then send everything to a single haproxy instance. Also, do you >> really need multiple studs ? BTW, what will you use to balance your >> studs and using what algorithm ? > > Yes, from my tests it looks that I will need probably more than two > studs in front for simplicity/high-availability paired with haproxy. > All machines will share pool of IP's managed by Wackamole/Heartbeat. > Balancing will be by DNS. In more advanced usages maybe by client > application (or additional routing server application which will tell > clients where to go next - but this is not sure). > >> Regards, >> Willy >> > > Cheers, > Kamil >
