On Mon, Oct 05, 2026 at 07:46:49PM +0200, Björn Jacke wrote: > Hi Lucas, > > On 10/5/26 18:20, Lukas Tribus wrote: > > Or if those would be 3 different ACLs then you would actually use the > > or operator in the use-server directive: > > use-server hrx0-chrome if requests-chrome-acl1 or requests-chrome-acl2 > > or requests-chrome-acl3 > > > > See section 7.2 of the docs for some examples. > > thanks a lot! This explains the issue very well. 7.2 is about using > pre-defined acls and it explains the usage of AND/OR operators. The previous > section (7.1) is actually the one which explains the acl definition. > > However it's maybe a bit hidden in section 7.1 that AND/OR operators are not > allowed for acl definitions, in any case I couldn't find explicitly in 7.1 > that AND/OR/&&/|| operators are not supported, I just assumed they would. > > Maybe the documentation could be clarified here a bit so that it explicitly > mentions that logical operators are not supported for acl definitions.
I agree, we've already seen a few similar mistakes once in a while that were not trivial to diagnose, and we even managed to detect a few of them to emit warnings (as long as they wouldn't prevent valid configs from working). I agree that maybe a reminder in the config could work, we just need to make certain people don't mistakenly read counter-examples as valid ones. > I > used logical operators in the past and they only kind of worked because they > fortunately were matches in the same variables before. :-) Maybe also a > warning for haproxy -c could be issued if it looks like a logical operator > is being used in an acl definition. This would improve usability a bit for > people who did the same mistake as me here. I'm fine with a warning as long as we find a way to enter these as valid strings and the warning explains how to get rid of it. Willy
