Apologies as this is *waaaaay* overdue as I didn't get the initial reply for whatever reason.

Thanks, Willy, for that initial response. We ended getting this implemented and things worked properly.

By the way you can currently do this using "expect-proxy layer4" and
"expect-netscaler-cip layer4" in tcp-request rules. If you already
know your clients addresses (which I'm sure you do), instead of leaving
the entry hardcoded you could put such rules instead.

Ah, right. So, in our setup this was just with Netscalers in the path, then on to the client, not having haproxy in the path. The dynamic detection of PROXY protocol vs. Netscaler CIP was on the backend server application side, not in haproxy config. So the question here was purely around whether this would be breaking the intention of the PROXY protocol *spec*, rather than looking for implementation/configuration information on haproxy being in path.

Now I'm having a question : shouldn't we simply move the netscaler CIP
parser to the proxy protocol parser and use a single option ? (ie accept-
proxy would validate both of them, and possibly future ones if needed).

It's important to decide before we release 1.7 :-)

That's somewhat out of my wheelhouse in terms of haproxy implementation specifics. It looks from the docs for 1.8 that this is still split, so ¯\_(ツ)_/¯

Hugo Slabbert       | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

Reply via email to