Hello Willy,
Now it have sense. This is a very clever use of a condition! Thanks for your time. Ricardo F. ---------------------------------------- > Date: Sat, 31 Aug 2013 08:54:49 +0200 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: Track headers with tcp-request in listen only work with "if HTTP" > > Hello Ricardo, > > On Thu, Aug 22, 2013 at 01:03:32PM +0200, Ricardo F wrote: >> Hello, >> >> I have been testing the connection tracking in the frontend based on headers, >> but it only work if the "if HTTP" option is set: >> >> tcp-request inspect-delay 10s >> tcp-request content track-sc0 hdr(x-forwarded-for,-1) if HTTP >> >> Without this option, the table doesn't fill, the connections aren't tracked. > > This is "normal", and due to the way the rules are evaluated. > > The tcp-request rules are a list of actions each having an optional condition. > The principle is to run over the rules and : > - if the condition is false, skip the rule > - if the condition is true, apply the rule > - if the condition is unknown, wait for more data > > Then when the rule is applied, it is performed whatever the type of rule > (track > or reject etc). > > As you can see, when doing "if HTTP", we abuse the condition mechanism to > ensure that the request buffer contains a complete HTTP request. It first > waits for data because until there are enough data in the buffer, we can't > tell whether it's HTTP or not, and when we can tell, the data you want to > track are available. > > If you try to track missing data, the track action is ignored (which allows > you to have multiple track actions on different data and track on the first > one which matches). > > I think it will be possible in the future to have the actions automatically > wait for the data by themselves since now (recently) we know if we're missing > something or not when doing the track action. But before doing so, I'd like > to ensure that we don't break some setups by doing so, typically the ones > that rely on the behaviour described above. If all fetch functions correctly > return "not found" that should be OK. I just want to be sure that none will > accidentely return "not found YET" in some corner cases that could be found > in valid setups. > > Best regards, > Willy > >
