mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-16 08:24:42 +00:00
BUG/MEDIUM: counters: fix track-sc* to wait on unstable contents
I've been facing multiple configurations which involved track-sc* rules in tcp-request content without the "if ..." to force it to wait for the contents, resulting in random behaviour with contents sometimes retrieved and sometimes not. Reading the doc doesn't make it clear either that the tracking will be performed only if data are already there and that waiting on an ACL is the only way to avoid this. Since this behaviour is not natural and we now have the ability to fix it, this patch ensures that if input data are still moving, instead of silently dropping them, we naturally wait for them to stabilize up to the inspect-delay. This way it's not needed anymore to implement an ACL-based condition to force to wait for data, eventhough the behaviour is not changed for when an ACL is present. The most obvious usage will be when track-sc is followed by any HTTP sample expression, there's no need anymore for adding "if HTTP". It's probably worth backporting this to 1.5 to avoid further configuration issues. Note that it requires previous patch.
This commit is contained in:
parent
b5975defba
commit
1b71eb581e
@ -1022,12 +1022,16 @@ int tcp_inspect_request(struct session *s, struct channel *req, int an_bit)
|
||||
* applies.
|
||||
*/
|
||||
struct stktable_key *key;
|
||||
struct sample smp;
|
||||
|
||||
if (stkctr_entry(&s->stkctr[tcp_trk_idx(rule->action)]))
|
||||
continue;
|
||||
|
||||
t = rule->act_prm.trk_ctr.table.t;
|
||||
key = stktable_fetch_key(t, s->be, s, &s->txn, SMP_OPT_DIR_REQ|SMP_OPT_FINAL, rule->act_prm.trk_ctr.expr, NULL);
|
||||
key = stktable_fetch_key(t, s->be, s, &s->txn, SMP_OPT_DIR_REQ | partial, rule->act_prm.trk_ctr.expr, &smp);
|
||||
|
||||
if (smp.flags & SMP_F_MAY_CHANGE)
|
||||
goto missing_data;
|
||||
|
||||
if (key && (ts = stktable_get_entry(t, key))) {
|
||||
session_track_stkctr(&s->stkctr[tcp_trk_idx(rule->action)], t, ts);
|
||||
|
Loading…
Reference in New Issue
Block a user