Hello to readers of the haproxy list,

This is my first-ever mail to the list, to propose my first-ever
contribution to the project, so I apologize in advance if anything here
runs afoul of your customs. I hope I've come close enough to make it
worth your while.

What I'm proposing has been coded up here:


And of course I can send a git-formatted patch to the list (but my
understanding is that an RFC discussion is preferred first).

The idea is probably best understood from a sample config:

    listen fe
        # ...
        server s0 ssl verify none forward-dst-sni

This is only relevant for the case of "forwarding" the client's
destination address, by using or * in the server config. When
the new option 'forward-dst-sni' is enabled for such a server, then for
clients who send an authority TLV in the PROXY header, the SNI for the
backend is set to the value of the TLV.

The use case is for clients who want to use haproxy's "address
forwarding" feature, but also need to communicate with backends via
haproxy that use SNI for "virtual hosing with SSL". With this feature
they can do that by using PROXYv2 and TLV.

The option is a NOP for servers that don't have the* config.
When it's enabled for such a server, and when the authority TLV is sent,
then the authority value overrides any SNI set in the client TLS
handshake. The rationale is that if a client goes to the trouble of
sending the TLV, then they want that to be used for the SNI (otherwise
they can just let the SNI be passed on from the client TLS).

I considered adding a test in reg-tests, but I don't see a way to set a
PROXY TLV value using VTest and haproxy (happy to be corrected if I'm
wrong). But we do have some varnishtest VTCs for it here, for a PR that
my colleague and I are working on for Varnish:



As for the coding, I suspect that my newbie status with haproxy shows
mostly in the way space is allocated for the authority string, which the
patch adds as a new field to struct connection. Since the feature is
likely to be used only rarely, it doesn't seem sensible to foresee all
of the space for a host name right in the struct. In the patch I have it
as a pointer to struct buffer, which is NULL unless the authority TLV is
read from the PROXY header.

It seemed to make sense to use a memory pool for the allocation, but it
also felt like overkill to add a new memory pool just for this feature.
So in the patch I'm just using the "trash pool".

Aside from the fact that the name "trash pool" makes me think that it
might not be meant to be used this way, if I understand correctly the
default allocation size is 16KiB, and users are advised not to reduce
it. That's far too large for a host name (usually max 255 bytes). So I
suspect that this may not be best practice for haproxy. Maybe define a
dedicated pool after all?

I'd be grateful for any feedback about the feature and the code (or
anything else). And of course I can send a patch to the list if you're

Geoff Simmons
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra├če 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to