Hi Willy, On Sat, Mar 17, 2012 at 8:58 AM, Willy Tarreau <w...@1wt.eu> 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
