Wietse Venema:
> Willy Tarreau:
> > On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote:
> > > Thanks Wietse, this is what I thought and found out during my
> > > experiments,That said, now knowing that only v1 is supported, may I ask
> > > whether you have considered implementing v2 support? I'm about to
> > > migrate to a setup where I'm behind a load balancer that only speaks v2.
> >
> > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
> > supported is quite easy, especially at the same level of support (i.e. no
> > TLV field support for TLS or whatever). You can have a look at
> > conn_recv_proxy() in haproxy:src/connection.c which supports the two
> > versions. Feel free to steal any code I wrote there, if that helps :-)
>
> I'm looking into this, and a Postfix-quality implementation including
> tests(!) is going to take more than a few hours. Primarily, because
> v2 uses a binary protocol, which complicates everything. I'll put a
> few hours in today.
I found that I first have to refactor the existing Postfix
implementation, because of a change in the haproxy message format.
The "diff -u" output is about 750 lines -- and that is refactoring
before adding v2 support.
The existing Postfix code completely separates the haproxy message
reader from the haproxy message parser. The v1 haproxy message has
a unique message terminator, and the haproxy message reader can
pull the entire message from the input queue before handing it off
to the haproxy message parser.
With the new protocol, there is no unique message terminator.
Instead, message length information is embedded in the message, and
the reader has to pull the message from the input queue after the
parser has figured out the message length. It's not super complicated,
but this back-and-forth between reading and parsing is complicating
the event-driven postscreen code a bit.
Wietse
