On Mon, Mar 19, 2012 at 6:32 PM, Willy Tarreau <w...@1wt.eu> wrote: > Hi Kamil, > > On Mon, Mar 19, 2012 at 11:59:51AM +0100, Kamil Gorlo wrote: >> "Cookies" are passed in two ways only: >> - as regular http cookies >> - as parameters in query string when first option is impossible >> >> There is no such thing as flash server farm. There is only one >> application server farm, they all understand HTTP. > > OK, thanks for clarifying this.
No problem, I'm glad we understand each other now :) >> > Do you have an example of a full request coming from your flash >> > application so that we get a better idea ? >> >> Typical session look like this (with Nginx setup where Nginx sets >> route_id cookie which provides stickiness with backend - backend >> supplies only session_id cookie which I prefer should not be used for >> routing purposes; of course we can change setup to one where backend >> supplies also route_id cookie): >> >> >> PUT /signin HTTP/1.1 >> >> X-bla: 42 >> << HTTP/1.1 200 OK >> << Set-Cookie: sessionID=312123 (this is from backend) >> << Set-Cookie: routeID=asd676 (this is from nginx, but could be changed) >> >> >> GET / HTTP/1.1 >> >> X-asd: 3123 >> >> X-qwe: 545 >> >> Cookie: sessionID=312123; routeID=asd676 >> << .... >> >> >> >> POST /upload/file.txt?sessionID=312123&routeID=asd676 >> << ... > > OK so this looks quite straightforward. > >> > 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. >> >> What do you mean by: "It would mean that most initial requests would >> not be sent to the server that delivered the cookie"? > > If we hash the request parameter (balance url_param), the server will > be determined by the result of a hash of the parameter. This means that > first request will be round-robined (no url parameter), and subsequent > requests will have the parameter which might map to a different server. Ok, understand. But this is not option for me it looks (balance url_param). >> For me ideal solution will be like in my first post. Everything works >> like with "cookie option" so there is only hashing involved > > The "cookie" statement does not hash anything, it inserts in responses > and matches in requests. Here however we'd have to make it match in the > query-string too. Yeah, I messed up everything. I forgot that "cookie option" does not hash anything (it's different than in nginx where cookie value is not provided in confuguration, but instead it's some hash). >> (there is >> no need to "learn" cookies from backend, store information in memory >> and share this information between haproxy instances), > > Indeed, it's easier if we don't have to learn anything! > >> but "cookie option" can optionally read cookie value from query string >> if not present in headers (as implemented in appsession if I >> understand correctly). > > Yes you understood correctly and it is clear to me now. > > I'll check how hard it can be to implement this. Great! Looking forward for good news :) > Cheers, > Willy > Cheers, Kamil
