]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: backend: fix balance hash calculation when using hash-type none
authorWilly Tarreau <w@1wt.eu>
Tue, 19 May 2026 16:18:23 +0000 (18:18 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 19 May 2026 17:11:25 +0000 (19:11 +0200)
commitcb5d98c495d21de9e45fc02a78a5ff06c0ac7b44
treec003a40c4258a15ad11065fd0d4c7c4105311d94
parentf2bf3483bae512aeaabb6c0fef0267ca84fe99cc
BUG/MINOR: backend: fix balance hash calculation when using hash-type none

The "hash-type xxx none" is broken for keys that are not in type string
because the sample fetch call casts them to SMP_T_BIN, that tends to
preserve the original format (integers, IP addresses etc), but the
gen_hash() function in case of BE_LB_HFCN_NONE expects to read a string
representing a number, that it parses to retrieve the value, and just
fails on many binary types. For example, the following just always
returns key 0:

    balance hash rand()
    hash type consistent none

An ugly workaround is to make sure the expression returns a string, for
example this:

    balance hash rand(),concat()
    hash type consistent none

In order to fix most cases here, we force the conversion to type string
when using BE_LB_HFCN_NONE, but a better approach would require a larger
rework and split gen_hash() or change it to accept an integer as well,
so that the caller could cast to SMP_T_INT for BE_LB_HFCN_NONE and pass
the resulting number already parsed with the least information loss. In
this case even IPv4 addresses would be preserved.

The current approach at least addresses the initially envisioned use
cases, and the limitations have been added to the doc. This can be
backported to 3.0 though it's not really important.
doc/configuration.txt
src/backend.c