bans are not forward compatible #4288
Comments
nigoroll
added a commit
to nigoroll/varnish-cache
that referenced
this issue
Feb 26, 2025
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 it 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 an unsupported argument or operator code are encountered, the newly added counters MAIN.bans_inval_arg1 and MAIN.bans_inval_oper are incremented, respectively. Fixes varnishcache#4288
nigoroll
added a commit
to nigoroll/varnish-cache
that referenced
this issue
Feb 26, 2025
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 varnishcache#4288
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
varnish-cache/bin/varnishd/cache/cache_ban.c
Line 550 in a62cb55
When loading a persistent storage from a later version which has a new ban format on an older version, a panic is triggered:
For this example, an
obj.lruban has been created with #4287 and then the storage loaded with 6d5aa36, which does not haveobj.lru.The text was updated successfully, but these errors were encountered: