]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: sink: don't learn srv port from srv addr
authorAurelien DARRAGON <adarragon@haproxy.com>
Thu, 9 Nov 2023 14:00:34 +0000 (15:00 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Fri, 10 Nov 2023 16:49:57 +0000 (17:49 +0100)
commitd710dfbaccf6a9c1aa969319849ed67dac29c154
treef6a0117e83e95e2669ad00029923ebb3d910eb96
parent64e0b6344240d28433b3d18d167768454962fda8
BUG/MINOR: sink: don't learn srv port from srv addr

Since 04276f3d ("MEDIUM: server: split the address and the port into two
different fields") we should not use srv->addr to store server's port
and rely on srv->svc_port instead.

For sink servers, we correctly set >svc_port upon server creation but
we didn't use it when initializing address for the connection.

As a result, FQDN resolution will not work properly with sink servers.
Hopefully, this used to work by accident because sink servers were
resolved using the PA_O_RESOLVE flag in str2sa_range(), which made the
srv->addr contain the port in addition to the address.

But this will fail to work when FQDN resolution is postponed because only
->svc_port will contain the proper server port upon resolution.

For instance, FQDN resolution with servers from log backends (which are
resolved as regular servers, that is, without the PA_O_RESOLVE) will fail
to work because of this.

This may be backported as far as 2.2 even though the bug didn't have
noticeable effects for versions below 2.9

[In 2.2, sink_forward_session_init() didn't exist it should be applied in
 sink_forward_session_create()]
src/sink.c