Thanks for the reply, Aleks. appsession lookup in URL does not seem to work for me.
The request, as it appears in HTTP access_log: 64.88.170.40 - - [28/Oct/2009:00:22:04 +0000] "POST /app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0" 200 1002 "-" "" And from haproxy.log: Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652 [28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 - JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10 ---- 0/0/0/0/0 0/0 "GET / HTTP/1.1" My haproxy.cfg: ... # when cookie persistence is required #cookie JSESSIONID prefix appsession jsessionid len 32 timeout 10800000 option httpclose capture cookie JSESSIONID len 46 # Example server line (with optional cookie and check included) server srv1 10.253.43.224:8000 cookie srv1 check inter 2000 rise 2 fall 3 server srv2 10.253.43.224:8000 cookie srv2 check inter 2000 rise 2 fall 3 ... Requests are still routed to both servers. It was suggested mod_jk and jvmRoute settings may be a factor (which seems true with server ID appended onto jsessionid - I don't have jvmRoute set anywhere); perhaps I'm overlooking something simple, but there's nothing apparent from the documentation I've read. I tried using the latest dev version of HAproxy too - didn't work. Thoughts? Thanks again for the feedback. Mike -----Original Message----- From: Aleksandar Lazic [mailto:al-hapr...@none.at] Sent: Tuesday, October 27, 2009 2:54 PM To: haproxy@formilux.org Subject: Re: Sticky session, dumb client Dear Michael, On Mon 26.10.2009 21:18, Robinson, Michael wrote: >I've got HAproxy 1.3.22 configured on two EC2 servers in front of two >Apache/Tomcat frontends serving a JSP-based mobile phone application. >The application requires session stickiness - I've tried every >documented alternative HAproxy offers for session persistence, >unfortunately without luck. The mobile device (well, our application) >does not support cookies and will not echo a modified jsessionid cookie >on subsequent requests. Two options seem ideal, but there are >roadblocks: > >1. appsession jsessionid len 52 timeout 1h > >However, since cookies aren't an option, we hoped to leverage >appsession URL lookup... which has the honor of being on the matrix of >all known bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on >10/18 (thanks for posting this, BTW!) > >Any ideas if/when this may make it into a stable release? It should work in the current release of haproxy. Do you have faced some problems, or bugs? >2. balance url_param jsessionid check_post > >This option could work... but it doesn't (for me, at least). Is the >config line wrong? Here's an example HTTP request from our log file: > >... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1" > >Can/should I just modify the source for url_param matching to look for >';' instead of '?' as a workaround? This could not work due to the fact that the jsessionid=... is not part or query string. from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt ### url_param The URL parameter specified in argument will be looked up in the query string of each HTTP GET request. . . ### I think it is not a good idea to change the delimiter from ';' to '?'. Maybe you will be happy with 'uri' as lb method? Maybe there should be parameter delimiter or regex for the load balancing algorithm uri? E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar BR Aleks