Hi Kamil, On Mon, Mar 19, 2012 at 09:02:25AM +0100, Kamil Gorlo wrote: > 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).
OK, so are those cookies always passed on the URL even with POST requests ? In what format are they passed ? Do they always have the same name as the cookie learned from the application or does the name need to be configurable ? Is the flash server farm shared with the HTTP farm ? Do you have an example of a full request coming from your flash application so that we get a better idea ? It is possible that current development version is already able to do everything you need using stick tables (stick store-response set-cookie() and stick match url_param()), but we need to check more precisely. If instead of learning the cookie we were doing a hash on it to always send the same cookie to the same server, would the application work or not ? It would mean that most initial requests would not be sent to the server that delivered the cookie, but all subsequent requests would be performed on the same server as the first one. > >> 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. OK so that implies stick table sharing if haproxy has to learn the cookies anyway since DNS balancing will send the requests to random nodes. Cookie hashing would work without sharing however. Regards, Willy
