On Thu, Oct 21, 2021 at 11:24:22AM +0200, Steve Hand wrote: > I wasted a day yesterday with this config. This all seemed to work > randomly, sometimes routing to default backend, sometimes routing to the acl > backend. > > The problem was I had 'mode tcp' in global and had to add 'mode http' to the > frontend, otherwise, the acl can't see the headers. > > Whilst I understand now why this was the case I was baffled for many hours > because it just worked but apparently randomly. > > Do you think a warning - "Use of acl rules in tcp mode won't match header > rules" ? Or something would be useful?
It can definitely match them and some users make use of that, these just require that you wait for the data to actually be there, because as TCP rules will execute as soon as the connection arrives, the request might very well not be there yet, hence the use of the tcp-request inspect-delay rule. With that said, use of TCP rules for HTTP processing ought to be avoided whenever possible, as it's both difficult to use and often limited (e.g. it makes no sense to recode an HTTP/2 request to HTTP/1 just for the sake of analyzing its contents at the TCP layer). In the past it used to happen when users were combining TCP and HTTP on a same frontend. Nowadays we can upgrade the connection from TCP to HTTP so that HTTP rules are usable even in a TCP frontend, limiting the need for TCP rules to TCP only. With newer versions (starting with 2.5) the doc starts to encourage to migrate to http-request rules for HTTP, and to use tcp-request session for lower layer stuff. My hope is that over the long term we stop seeing that many tcp-request rules for L7 processing. Cheers, Willy
