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
