Hi, the only way you could do what you want for now is using stick tables (and haproxy 1.5-dev17). You can learn the Set-Cookie from the server and match the Cookie in the table from the client. That way, all the request from a user will be sent to the same server, from the first to the last one.
Today, haproxy is able to hash a HTTP header for load-balancing, so a configuration like: balance hdr(Cookie) could do the trick, but it means that ALL clients cookie to load-balance. And worste, since there is no phpsessionid cookie on the first request, there are chances that the first and the second requests won't be routed to the same server. I guess it would be possible soon to have a: balance cook(PHPSessionID) but it won't fix the sticking issue between first and second request since the cookie is not present in the first request. So if you really want using the algorithm method, you must be able to share cookies between your backend servers, only lucky people will be able to get authenticated. Well, maybe there are some dirty tricks like managing a farm for cookie-less clients and configuring PHP to learn an unknown session on the fly. Baptiste On Sun, Feb 3, 2013 at 2:03 AM, Alex Davies <a...@davz.net> wrote: > Hi All, > > What is the best way to configure haproxy to hash based on an application > cookie (such as PHPSESSID), in a way that is consistent (meaning multiple > haproxy servers will route to the same backend), ideally including the > ability to weight backends (the configuration would clearly have to be the > same on these different boxes). > > appsession obviously allows this for a single HAProxy server, but it seems > from the documentation that it generates a server based on the hash at the > start of each session, so if the same session hit a different but > identically configured haproxy server it would end up with a > > Thanks, > > -Alex
