Hello Björn,
On Mon, 5 Oct 2026 at 19:46, Björn Jacke <[email protected]> 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. 7.2 contains examples of pre-defined, user-defined and anonymous ACLs and combinations of them and explains how to use them to form conditions, including with logical operators. > 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. The point is that in a ACL you define patterns. A syntax like this: acl url_static path_end .gif .png .jpg .css .js can never support logical operators in a place where patterns belong for obvious reasons. > Maybe the documentation could be clarified here a bit so that it > explicitly mentions that logical operators are not supported for acl > definitions. 7.1.0 is long and verbose (over 2000 words), I fear a small clarification maybe easily overlooked. Also 7.1 indicates criterion specific operators (not the logical operators we are talking about), making this possibly more confusing. If you have a specific suggestion I suggest you send a patch; usually the best documentation changes do not come from developers. To clarify: I'm not saying the status quo is good, I'm saying people run into this for as long as I work with haproxy, efforts to improve this have been made in the past and it sounds a lot easier to fix than it actually is. For example see the previous discussion here: https://www.mail-archive.com/[email protected]/msg44568.html A single added sentence in the docs is probably not going to change much for the people running into it, because they start with the conviction that this is supported (otherwise they would not put it there). Perhaps now with AI going through our docs pointing this out more explicitly can indeed help users asking a LLM for advice on this. Also by calling this out specifically we possibly avoid that LLMs hallucinate that this is supported (confusing ACL definition with ACL usage). > Maybe also a warning for haproxy -c could be issued if it > looks like a logical operator is being used in an acl definition. That's what -dD does (since haproxy-3.0) which you can add to -c. In your case it raises the following diagnostic warnings: [DIAG] (1805) : config : parsing [acl-basic-errors.cfg:20] : pattern '||' looks like a failed attempt at using an operator inside a pattern list [DIAG] (1805) : config : parsing [acl-basic-errors.cfg:20] : pattern 'hdr(sec-ch-ua)' suspiciously looks like a known acl keyword [DIAG] (1805) : config : parsing [acl-basic-errors.cfg:20] : pattern '||' looks like a failed attempt at using an operator inside a pattern list [DIAG] (1805) : config : parsing [acl-basic-errors.cfg:20] : pattern 'hdr(user-agent)' suspiciously looks like a known acl keyword Instead of running with the config check you can also combine it with zero-warning (-dW) for startup, so that such a configuration is flat out rejected: [DIAG] (2641) : config : parsing [acl-basic-errors.cfg:20] : pattern '||' looks like a failed attempt at using an operator inside a pattern list [DIAG] (2641) : config : parsing [acl-basic-errors.cfg:20] : pattern 'hdr(sec-ch-ua)' suspiciously looks like a known acl keyword [DIAG] (2641) : config : parsing [cert/acl-basic-errors.cfg:20] : pattern '||' looks like a failed attempt at using an operator inside a pattern list [DIAG] (2641) : config : parsing [cert/acl-basic-errors.cfg:20] : pattern 'hdr(user-agent)' suspiciously looks like a known acl keyword [DIAG] (2641) : Created 2 threads split into 1 groups [ALERT] (2641) : Some warnings were found and 'zero-warning' is set. Aborting. Hope this helps, Lukas
