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: [email protected]
pgp key: B178313E | also on Signal
