Hi,
Now everything is working - thank you very much guys for your commitment !!
Without your help, it wouldn't work for me.
I attach my current working config just if somebody comes here with similar
problem:
global
stats socket /tmp/haproxy.sock
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend app
bind *:8080
default_backend web_servers
backend web_servers
balance roundrobin
option http-server-close
stick-table type integer size 200k expire 30m store http_req_cnt
tcp-request content track-sc0 urlp(SID,?)
tcp-request content reject if { sc0_http_req_cnt gt 2 }
tcp-request inspect-delay 10s
server web01 192.168.9.128:80 check inter 1000
server web02 192.168.9.129:80 check inter 1000
--
Przemysław Hejman
e-mail: [email protected]
TouK sp. z o.o. s.k.a.
02-389 Warszawa, al. Bohaterów Września 9
http://touk.pl
Wiadomość napisana przez Cyril Bonté <[email protected]> w dniu 28 paź 2013,
o godz. 09:26:
> Hi Willy,
>
> Le 28/10/2013 07:36, Willy Tarreau a écrit :
>> Good analysis. Indeed, "tcp-request track-sc*" does not wait for
>> anything (eg: for connection we must not wait). It is documented
>> as tracking only what is found. The proper method to wait for
>> contents if needed is to rely on a condition for the track rule
>> to take action :
>
> Oh yes, I better understand the last paragraph for the "tcp-request content"
> documentation now (probably read it too fast) ;-)
>
> I saw in the code that a condition would wait (that's why i also added a
> return for the track-sc test) but I didn't realized that the behaviour was
> documented.
>
> Well, I hope that Przemyslaw's issue is now gone, then.
>
>
> --
> Cyril Bonté
>
