Hi Dennis, On Fri, Feb 12, 2016 at 03:47:41AM +0100, Dennis Jacobfeuerborn wrote: > After sending the message I thought about this some more and then it > suddenly became obvious: "tcp-request connection" only sees the tcp > connections and since I'm using the abstract namespace sockets for the > send-proxy call the plain http frontend obviously never gets to see the > actual tcp connections from the SSL frontend. > > So the fix was to replace "tcp-request connection" with "tcp-request > content".
Yes indeed. The "tcp-request connection" ruleset is applied immediately after accept(). You can't do anything earlier. > The question now is if that has any negative impact on performance? If > not why would one not always use the "content" variant since that seems > to be more powerful than its "connection" sibling? The impact is usually minimal. The "tcp-request connection" rules are made to perform some infrastructure-level filtering. Basically what you would normally do with iptables could be moved into haproxy if relevant. This ruleset allows to block incoming connections at a very high rate. Typically it's possible to resists connection floods above 300000 connections per second per core. It's also nice to reject connections not coming from the allowed reverse proxies for example. Then in "tcp-request content" rules, as you noticed, the proxy protocol header has already been parsed. Thus you can be sure that it comes from trusted senders and that the apparent source address is valid. Hoping this helps, Willy
