Hello Ciprian, thank you very much for your very detailed answer.
1) While seaching and failing I came to the conclusion what you said, that I have to introduce a variable from which I can fetch via var(varname). So you confirmed what I assumed. 2) It's not a security critical aspect. The hash algorithm should be feasible. 3) From the beginning I was sure to use a binary field with enough bytes to hold the src representation and the hash value together without overflow for the sticky-table key. Thank you very much for the time you spent answering me. Best wishes Andreas > -----Ursprüngliche Nachricht----- > Von: Ciprian Dorin Craciun <ciprian.crac...@gmail.com> > Gesendet: Donnerstag, 13. Februar 2025 10:53 > An: Andreas Mock <andreas.m...@drumedar.de>; haproxy@formilux.org > Betreff: Re: Can't find a solution for a config problem > > On 2/12/25 17:25, Andreas Mock wrote: > > http-request track-sc0 capture.req.hdr(0),lower,crc32c(1) => does work > > > > So, my question: How can I construct a key consisting of both parts > > in any way concatenated? Is is possible as a oneliner on > > > > http-request track-sc0 <the stuff i need> > > > > or do I have to do some intermediate variable assignment? > > > > Any hint (or solution) would be very appreciated. > > > > I don't think you can easily do it in one go, but you could do something > on these lines: > > * use `set-var-fmt` to set a string variable to concatenation of both > the hostname and the source, something like: > > http-request set-var-fmt(txn.track_key) "%[src] %[req.fhdr(host)]" > > * then use your original idea to convert this string into a number with > something like the `xxh3` converter and use that as the key of your table; > > > Note that `crc32c`, and even `xxh3` could lead to collisions, and if you > use this for security purposes, then perhaps you should use `hmac` (see > the documentation), or at least use the `xxh3(seed)` variant. > > Also note, that by default track tables of type `integer` are 32 bit in > size, thus if collisions are an issue, perhaps you should switch to > `type binary len 16` (for 128 bits), and use the appropriate convertor. > > Finally, don't forget to pay special attention to canonicalization of > the concatenation, so that (if this is used for security purposes), the > attacker can't spoof something via the `Host` header. (My proposal of > `%[src] ...` should be OK.)
