Hi Willy,
The 1.4 seems not to work, for example I have the following:
frontend xx xxxx:80
mode http
tcp-request inspect-delay 30s
acl to_delay hdr_reg Opera.*
tcp-request content accept if to_delay WAIT_END
Maybe it is because of the capture cookie or redirect which I have further?
P.S.: Sorry for the William
Willy Tarreau wrote:
Hi Andrew,
On Mon, Aug 03, 2009 at 02:18:21AM +0200, Andrew Azarov wrote:
BTW, with 1.4 you could already do this without additional work,
because in 1.4 you can use HTTP ACLs in TCP rules. You just need
to wait for a whole HTTP request first. It would look like this :
1 frontend XXX
2 mode http
3 tcp-inspect delay 30s
4 tcp-request content reject if ! HTTP
5 acl to_delay hdr_sub(user-agent) -i Opera
6 ( as many other tests as you want )
7 tcp-request content accept if to_delay WAIT_END
What this does :
3) set max tcp content inspection delay to the pause you
want to induce
4) wait for a complete HTTP request. As long as the TCP contents
look like HTTP but the request is not complete, the rule will
block and return to the caller that it wants more data. If it
sees it's not valid HTTP protocol, it will drop the request.
If it sees it's a complete HTTP request, it will pas on to
next rules.
5) write as many tests as you want for the to_delay, which will
indicate what criteria will introduce a delay. You can also
write as many ACLs as you want and combine them later.
7) We say that we accept the request if the ACL "to_delay" is
matched as well as the implicit "WAIT_END" ACL. The trick
here is that this WAIT_END only matches once the timeout
strikes. So it will be evaluated only if the to_delay is
also validated, and will cause a pause for those requests.
If the to_delay ACL is not matched, then the next rules are
evaluated. Once there aren't any more, we get an automatic
accept, which happens for other traffic.
I really encourage you to give it a try, as it may help you solve
your issues without wasting time on code, and it will offer you a
much more flexible mechanism too.
Regards,
Willy