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. > > 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. > 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. > (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. Cheers, Willy
