RE: Sticky session, dumb client

2009-10-28 Thread Robinson, Michael
Thanks again, Aleks and Willy.

This is finally working - not an elegant solution, but as a workaround a 
SERVERID cookie can be appended onto the request header using Apache mod_header 
that mimics the one inserted by HAproxy on outgoing responses.  So, basically 
HAproxy sees a "normal" client request, and "cookie SERVERID insert indirect 
nocache" can work as documented.  This is possible because the jsessionid value 
passed in the URL has the originating server appended to the session 
information already (apparently that is what mod_jk uses and our software was 
originally written with mod_jk in mind).

Thanks again for the help!

-Mike

-Original Message-
From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
Sent: Wednesday, October 28, 2009 1:12 AM
To: Robinson, Michael
Cc: haproxy@formilux.org
Subject: Re: Sticky session, dumb client

On Die 27.10.2009 20:37, Robinson, Michael wrote:
>Thanks for the reply, Aleks.
>
>appsession lookup in URL does not seem to work for me.

Please can you rebuild haproxy with

DEBUG=-DDEBUG_HASH

and run it with -db to see what's in the hash.

>The request, as it appears in HTTP access_log:
>
>64.88.170.40 - - [28/Oct/2009:00:22:04 +] "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"

This lines are not from the same client or requst right?!

BR

Aleks

>My haproxy.cfg:
>
>   ...
># when cookie persistence is required
>#cookie JSESSIONID prefix
>appsession jsessionid len 32 timeout 1080
>option httpclose
>capture cookie JSESSIONID len 46
># Example server line (with optional cookie and check included)
>serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 
> rise 2 fall 3
>serversrv2 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
>
>
>
>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 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
>



Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Aleksandar Lazic

On Mit 28.10.2009 17:12, Dirk Taggesell wrote:

On Wed, Oct 28, 2009 at 2:19 PM, Jeffrey 'jf' Lim wrote:

what version of haproxy is this?




Ah sorry. It is 1.3.17


Is it possible to update to 1.3.22 yust to be on the save side ;-)

### http://haproxy.1wt.eu/
Let's put it short : those of you running 1.3.15.2, 1.3.16 or 1.3.17 are doomed
###


And one other thing to look at - what is the log line like for this
particular request?



Oct 28 13:50:57 127.0.0.1 haproxy[3282]:
88.217.248.214:42160[28/Oct/2009:13:50:57.690] cookietracker
cookietracker/cookietracker
1/0/0/-1/3 502 204 - - SL-- 2000/0/0/0/0 0/0 "GET /c HTTP/1.1"



S : the TCP session was unexpectedly aborted by the server, or the
server explicitly refused it.
L : the proxy was still transmitting LAST data to the client while the
server had already finished. This one is very rare as it can only
happen when the client dies while receiving the last packets.

Do you have any error messages in the Server logs?


followed after some seconds by about several dozen of these lines:
Oct 28 13:52:01 127.0.0.1 haproxy[3282]:
10.224.115.160:43562[28/Oct/2009:13:51:11.732] trackertest
trackertest/ -1/1/0/-1/5 0
0 - - sL-- 1902/1902/1902/0/0 0/0 ""

10.224.115.160 is the server's ip NATed address (Amazon EC2)


s : the server-side timeout expired while waiting for the server to send
or receive data.

L : the proxy was still transmitting LAST data to the client while the
server had already finished. This one is very rare as it can only
happen when the client dies while receiving the last packets.

As the previous poster have said haproxy wait for content of the
request.

As in rfc 2616 described:

###
10.2.5 204 No Content

   The server has fulfilled the request but does not need to return an
   entity-body, and might want to return updated metainformation. The
   response MAY include new or updated metainformation in the form of
   entity-headers, which if present SHOULD be associated with the
   requested variant.

   If the client is a user agent, it SHOULD NOT change its document view
   from that which caused the request to be sent. This response is
   primarily intended to allow input for actions to take place without
   causing a change to the user agent's active document view, although
   any new or updated metainformation SHOULD be applied to the document
   currently in the user agent's active view.

   The 204 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.
###

maybe haproxy should take care of this ;-)

Aleks



Re: rewriting urls

2009-10-28 Thread XANi
Hi,
On Wed, 28 Oct 2009 12:39:03 +, Matt  wrote:
> Think I figured it out now.
> 
> I'm using an acl to push the request to a backend that contains the
> external server.  In the backend i'm then rewriting the url.
> 
> What are the reasons most people seem to front haproxy with apache or
> nginx?
SSL/Compression ?

Regards
Mariusz

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
http://devrandom.pl



signature.asc
Description: PGP signature


Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Dirk Taggesell
BTW: sorry for the somewhat wierd looking thread. I forgot to manually
include haproxy@formilux.org as recipient and manually re-sent it afterwards
to the list  - for the sake of completeness.

And I am forced to use this abomination of a mail reader called google mail,
because my mail relay at 1und1.de won't deliver mails to the
formilux.orgmail server. It complains with:

A message that you sent could not be delivered to one or more of
its recipients. The following addresses failed:

  

domain name system error:
host mail.formilux.org:
mail exchanger has no ip addresses

Which is not entirely true, but mail.formilux,org is a CNAME instead of an A
record and maybe the 1und1 server is complaining about that.


Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Dirk Taggesell
On Wed, Oct 28, 2009 at 3:30 PM, Jeffrey 'jf' Lim wrote:


> it looks like Karsten's suspicion is correct. Try adding the
> 'Content-length: 0' header. haproxy is still expecting more data from the
> backend. (It apparently does not know about status 204???).
>

thanks, Jeffrey and Karsten,

I forwarded the suggestion to our developers (I am only the humble
infrastructure guy :D )   and we'll see whether it works.


Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Dirk Taggesell
On Wed, Oct 28, 2009 at 2:19 PM, Jeffrey 'jf' Lim wrote:

what version of haproxy is this?
>

Ah sorry. It is 1.3.17


>  do 200 requests from the same backend passed through haproxy work?
>

Yes, haproxy generally works when i test it with an ordinary Apache as
back-end instead of the custom app.


> I can't say that i've looked too closely at the code for this, but, I get
> the impression that haproxy generally returns 502 for stuff that it cannot
> recognize.
>

I am afraid it is so. There's some paragraphs in the documentation which
suggest that.


> And one other thing to look at - what is the log line like for this
> particular request?
>

Oct 28 13:50:57 127.0.0.1 haproxy[3282]:
88.217.248.214:42160[28/Oct/2009:13:50:57.690] cookietracker
cookietracker/cookietracker
1/0/0/-1/3 502 204 - - SL-- 2000/0/0/0/0 0/0 "GET /c HTTP/1.1"

followed after some seconds by about several dozen of these lines:
Oct 28 13:52:01 127.0.0.1 haproxy[3282]:
10.224.115.160:43562[28/Oct/2009:13:51:11.732] trackertest
trackertest/ -1/1/0/-1/5 0
0 - - sL-- 1902/1902/1902/0/0 0/0 ""

10.224.115.160 is the server's ip NATed address (Amazon EC2)


Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Dirk Taggesell
On Wed, Oct 28, 2009 at 2:05 PM, John Lauro wrote:

>  You could run mode tcp if you setup haproxy in transparent mode .
>
The docs say: Note that contrary to a common belief, this option does

NOT make HAProxy present the client's IP to the server when establishing
the connection.

Which makes sense. And it doesn't work.


RE: Backend sends 204, haproxy sends 502

2009-10-28 Thread John Lauro
Oops, me bad.  that's technically right.   I was burned by this terminology
too.   What is considered transparent mode is actually good if you want to
proxy the world instead of your servers, and it can be combined with usesrc.

 

Anyways, what I should of said was you can make Haproxy present the client's
IP with "source   haproxyinterfaceip usesrc client"  

 

Might be good if the transparent mode had a reference to usesrc..

 

 

From: Dirk Taggesell [mailto:dirk.tagges...@googlemail.com] 
Sent: Wednesday, October 28, 2009 9:48 AM
To: John Lauro
Subject: Re: Backend sends 204, haproxy sends 502

 

 

On Wed, Oct 28, 2009 at 2:05 PM, John Lauro 
wrote:

You could run mode tcp if you setup haproxy in transparent mode .

The docs say: Note that contrary to a common belief, this option does






NOT make HAProxy present the client's IP to the server when establishing


the connection.

Which makes sense. And it doesn't work.

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.29/2455 - Release Date: 10/28/09
09:34:00



Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Jeffrey 'jf' Lim
On Wed, Oct 28, 2009 at 9:54 PM, Dirk Taggesell <
dirk.tagges...@googlemail.com> wrote:

> On Wed, Oct 28, 2009 at 2:19 PM, Jeffrey 'jf' Lim wrote:
>
> what version of haproxy is this?
>>
>
> Ah sorry. It is 1.3.17
>
>
>>  do 200 requests from the same backend passed through haproxy work?
>>
>
> Yes, haproxy generally works when i test it with an ordinary Apache as
> back-end instead of the custom app.
>
>
>> I can't say that i've looked too closely at the code for this, but, I get
>> the impression that haproxy generally returns 502 for stuff that it cannot
>> recognize.
>>
>
> I am afraid it is so. There's some paragraphs in the documentation which
> suggest that.
>
>
>> And one other thing to look at - what is the log line like for this
>> particular request?
>>
>
> Oct 28 13:50:57 127.0.0.1 haproxy[3282]: 
> 88.217.248.214:42160[28/Oct/2009:13:50:57.690] cookietracker 
> cookietracker/cookietracker
> 1/0/0/-1/3 502 204 - - SL-- 2000/0/0/0/0 0/0 "GET /c HTTP/1.1"
>
>
it looks like Karsten's suspicion is correct. Try adding the
'Content-length: 0' header. haproxy is still expecting more data from the
backend. (It apparently does not know about status 204???).

And to answer Karsten's question: the content-length header isn't strictly
mandated (it's a 'SHOULD').

-jf




> followed after some seconds by about several dozen of these lines:
> Oct 28 13:52:01 127.0.0.1 haproxy[3282]: 
> 10.224.115.160:43562[28/Oct/2009:13:51:11.732] trackertest 
> trackertest/ -1/1/0/-1/5 0
> 0 - - sL-- 1902/1902/1902/0/0 0/0 ""
>
> 10.224.115.160 is the server's ip NATed address (Amazon EC2)
>


Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Karsten Elfenbein
Hi,

most 502 errors in haproxy responses come from "bad" backend responses.
Could you try adding a "Content-Length: 0" header to the backend response? I 
don't know if RFC requires it in a 204 response.

btw. the expires date in your setcookie looks a bit strange. 0059, 1959 or 
2059?

Karsten

Am Mittwoch, 28. Oktober 2009 schrieben Sie:
> bash-3.2$ curl --verbose "http://cm01.example.com:8000/c";
> * About to connect() to cm01.example.com port 8000 (#0)
> *   Trying 22.33.44.55... connected
> * Connected to cm01.example.com (22.33.44.55) port 8000 (#0)
> 
> > > GET /c HTTP/1.1
> > > User-Agent: curl/7.19.6 (i386-apple-darwin9.8.0) libcurl/7.19.6
> 
> OpenSSL/0.9.8k zlib/1.2.3
> 
> > > Host: cm01.example.com:8000
> > > Accept: */*
> 
> < HTTP/1.1 204 No Content
> < Date: Wed, 28 Oct 2009 11:56:44 GMT
> < Server: Jetty/5.1.11RC0 (Linux/2.6.21.7-2.fc8xen amd64 java/1.6.0_16
> < Expires: Thu, 01 Jan 1970 00:00:00 GMT
> < Set-Cookie: pid=08f0b764185;Path=/;Domain=.example.com;Expires=Thu,
> 16-Oct-59 11:56:44 GMT
> < Connection: close
> <
> * Closing connection #0
> 



Re: Backend sends 204, haproxy sends 502

2009-10-28 Thread Jeffrey 'jf' Lim
On Wed, Oct 28, 2009 at 9:02 PM, Dirk Taggesell <
dirk.tagges...@googlemail.com> wrote:

> Hi all,
>
> I want to load balance a new server application that generally sends
> http code 204 - to save bandwidth and to avoid client-side caching.
> In fact it only exchanges cookie data, thus no real content is delivered
> anyway.
>
> When requests are made via haproxy, the backend - as intended - delivers
> a code 204 but haproxy instead turns it into a code 502. Unfortunately I
> cannot use tcp mode because the server app needs the client's IP
> address. Is there something else I can do?
>
>
what version of haproxy is this? do 200 requests from the same backend
passed through haproxy work? I can't say that i've looked too closely at the
code for this, but, I get the impression that haproxy generally returns 502
for stuff that it cannot recognize.

And one other thing to look at - what is the log line like for this
particular request?

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
   -- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228


RE: Backend sends 204, haproxy sends 502

2009-10-28 Thread John Lauro
You could run mode tcp if you setup haproxy in transparent mode .

 

From: Dirk Taggesell [mailto:dirk.tagges...@googlemail.com] 
Sent: Wednesday, October 28, 2009 9:03 AM
To: haproxy@formilux.org
Subject: Backend sends 204, haproxy sends 502

 

Hi all,

I want to load balance a new server application that generally sends
http code 204 - to save bandwidth and to avoid client-side caching.
In fact it only exchanges cookie data, thus no real content is delivered
anyway.

When requests are made via haproxy, the backend - as intended - delivers
a code 204 but haproxy instead turns it into a code 502. Unfortunately I
cannot use tcp mode because the server app needs the client's IP
address. Is there something else I can do?

Request directly to the appserver:

bash-3.2$ curl --verbose "http://cm01.example.com:8000/c";
* About to connect() to cm01.example.com port 8000 (#0)
*   Trying 22.33.44.55... connected
* Connected to cm01.example.com (22.33.44.55) port 8000 (#0)
> > GET /c HTTP/1.1
> > User-Agent: curl/7.19.6 (i386-apple-darwin9.8.0) libcurl/7.19.6
OpenSSL/0.9.8k zlib/1.2.3
> > Host: cm01.example.com:8000
> > Accept: */*
> >
< HTTP/1.1 204 No Content
< Date: Wed, 28 Oct 2009 11:56:44 GMT
< Server: Jetty/5.1.11RC0 (Linux/2.6.21.7-2.fc8xen amd64 java/1.6.0_16
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: pid=08f0b764185;Path=/;Domain=.example.com;Expires=Thu,
16-Oct-59 11:56:44 GMT
< Connection: close
<
* Closing connection #0

The above is how it is intended to look. And now via haproxy:

bash-3.2$ curl --verbose "http://cm01.example.com/c";
* About to connect() to cm01.example.com port 80 (#0)
*   Trying 22.33.44.55... connected
* Connected to cm01.example.com (22.33.44.55) port 80 (#0)
> > GET /c HTTP/1.1
> > User-Agent: curl/7.19.6 (i386-apple-darwin9.8.0) libcurl/7.19.6
OpenSSL/0.9.8k zlib/1.2.3
> > Host: cm01.example.com
> > Accept: */*
> >
* HTTP 1.0, assume close after body
< HTTP/1.0 502 Bad Gateway
< Cache-Control: no-cache
< Connection: close
< Content-Type: text/html
<
502 Bad Gateway
The server returned an invalid or incomplete response.

* Closing connection #0

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.29/2455 - Release Date: 10/28/09
09:34:00



Backend sends 204, haproxy sends 502

2009-10-28 Thread Dirk Taggesell
Hi all,

I want to load balance a new server application that generally sends
http code 204 - to save bandwidth and to avoid client-side caching.
In fact it only exchanges cookie data, thus no real content is delivered
anyway.

When requests are made via haproxy, the backend - as intended - delivers
a code 204 but haproxy instead turns it into a code 502. Unfortunately I
cannot use tcp mode because the server app needs the client's IP
address. Is there something else I can do?

Request directly to the appserver:

bash-3.2$ curl --verbose "http://cm01.example.com:8000/c";
* About to connect() to cm01.example.com port 8000 (#0)
*   Trying 22.33.44.55... connected
* Connected to cm01.example.com (22.33.44.55) port 8000 (#0)
> > GET /c HTTP/1.1
> > User-Agent: curl/7.19.6 (i386-apple-darwin9.8.0) libcurl/7.19.6
OpenSSL/0.9.8k zlib/1.2.3
> > Host: cm01.example.com:8000
> > Accept: */*
> >
< HTTP/1.1 204 No Content
< Date: Wed, 28 Oct 2009 11:56:44 GMT
< Server: Jetty/5.1.11RC0 (Linux/2.6.21.7-2.fc8xen amd64 java/1.6.0_16
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: pid=08f0b764185;Path=/;Domain=.example.com;Expires=Thu,
16-Oct-59 11:56:44 GMT
< Connection: close
<
* Closing connection #0

The above is how it is intended to look. And now via haproxy:

bash-3.2$ curl --verbose "http://cm01.example.com/c";
* About to connect() to cm01.example.com port 80 (#0)
*   Trying 22.33.44.55... connected
* Connected to cm01.example.com (22.33.44.55) port 80 (#0)
> > GET /c HTTP/1.1
> > User-Agent: curl/7.19.6 (i386-apple-darwin9.8.0) libcurl/7.19.6
OpenSSL/0.9.8k zlib/1.2.3
> > Host: cm01.example.com
> > Accept: */*
> >
* HTTP 1.0, assume close after body
< HTTP/1.0 502 Bad Gateway
< Cache-Control: no-cache
< Connection: close
< Content-Type: text/html
<
502 Bad Gateway
The server returned an invalid or incomplete response.

* Closing connection #0


Re: rewriting urls

2009-10-28 Thread Matt
Think I figured it out now.

I'm using an acl to push the request to a backend that contains the
external server.  In the backend i'm then rewriting the url.

What are the reasons most people seem to front haproxy with apache or nginx?

Thanks,

Matt

2009/10/27 Matt :
> Hi,
>
> I've managed to rewrite urls using the reqrep function but only for
> urls which are on the same domain.
>
> This works
> reqrep ^([^\ ]*)\ /my.xml(.*)     \1\ /foo/bar/my.xml\2
>
> but this doesn't seem to
> reqrep ^([^\ ]*)\ /my.xml(.*)     \1\ http://newdomain.com/foo/bar/my.xml\2
>
> I'd like to use the acl method but I see this only does redirect and
> not proxying? is this still the case?
>
> In apache I guess i'd just do this:
> RewriteRule ^/my.xml$ http://newdomain/foo/bar/my.xml [P,L,QSA]
>
> Couldn't seem to find many examples in the docs that would help on this.
>
> Thanks,
>
> Matt
>



Re: Sticky session, dumb client

2009-10-28 Thread Aleksandar Lazic

On Die 27.10.2009 20:37, Robinson, Michael wrote:

Thanks for the reply, Aleks.

appsession lookup in URL does not seem to work for me.


Please can you rebuild haproxy with

DEBUG=-DDEBUG_HASH

and run it with -db to see what's in the hash.


The request, as it appears in HTTP access_log:

64.88.170.40 - - [28/Oct/2009:00:22:04 +] "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"


This lines are not from the same client or requst right?!

BR

Aleks


My haproxy.cfg:

...
   # when cookie persistence is required
   #cookie JSESSIONID prefix
   appsession jsessionid len 32 timeout 1080
   option httpclose
   capture cookie JSESSIONID len 46
   # Example server line (with optional cookie and check included)
   serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 rise 
2 fall 3
   serversrv2 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



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 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