Willy, On 10/27/21 6:32 PM, Willy Tarreau wrote:
So the question is (as you see me coming), is it acceptable to fix this in 2.5+ by making var() match the doc, returning the type "any", and mandathing the matching method, implying that this bogus config which does not work:http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) lt 0 } will need to be written like this: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) -m int lt 0 } My lock checks showing that roughly 30% of the configs not using -m are bogus does not even make me want to continue to support this without telling users their config will not work. And any config fixed with this will also be fixed and start to work for earlier versions. I would love to have the option to emit a warning for older ones but I really cannot promise anything. I expect that 2.5 users will be experienced users and that it will not be a big deal to rely on this to fix their configs once for all. I'd rather not do this during an odd->even switch however. I'd like to get some opinions quickly on this as while the error will just be a one-liner fix, the warnings are way more complicated and will take some time.
Personally I'd prefer to see my config loudly rejected if it is incorrect than it silently working incorrectly. It's not like I'm going to roll out 2.5 in my fleet without testing the config at least once.
So: +1 to make this an error. Best regards Tim Düsterhus
