You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cache_ban: Forward compatibility for the binary ban representation
Our ban expressions (like "obj.age > 20s") are represented in a binary format
(see top of cache_ban.h) which allows for forward compatibility, yet at the
respective places we currently just trigger an assertion failure if we hit an
unknown argument or operator code.
This commit brings forward compatibility such that, when bans are loaded from
persistent storage into older code which does not yet support newly introduced
binary codes, we no longer panic.
Ban evaluation:
For bans, evaluating an expression to "true" is always "correct" in that the
cache would not deliver banned content. It might cause objects to be removed
from cache, but that is at least not incorrect. So the fail safe action this
code takes is to always evaluate unknown ban expressions to true.
CLI ban.list:
For unsupported ban expressions, the unknown argument or operator codes are
formatted as "(0x%02x)" with the string "UNSUPPORTED" as the user-specified
argument. For example:
1740567193.765849 0 - (0x20) > UNSUPPORTED && obj.http.foo ~ 377.266
(note that here the operator > is supported and printed as such, and the ban
contains one unsupported and one supported expression)
Logging:
For each unsupported argument or operator code, an Error VSL is output exactly
once to vxid 0.
Statistics:
Whenever unsupported argument or operator codes are encountered, the newly added
counters MAIN.bans_inval_arg1 and MAIN.bans_inval_oper are incremented,
respectively.
Fixes#4288
0 commit comments