Hi Willy, On Fri, Jul 18, 2025 at 11:53 AM Willy Tarreau <[email protected]> wrote: > No, it does not "forward" PROXY headers. The PROXY header is decoded > on one side to fill some information that might be needed during the > processing (protocol, source IP address, etc), and is used to replace > such info with those found in the header. Then on the output, you're > asking for a PROXY header to be produced, based on some information > that are available. As you can see there's no such notion of forwarding > here. The PROXY header is really only meant to be hop-by-hop, so each > component in the chain writes the one it was configured to write.
Got it. Stopping to think about it in the new light of your explanation, it wouldn't make sense to simply forward a PROXY header---just like it doesn't with Ethernet frames, on a crude comparison. > I must say I'm a bit embarrassed, because I'm seeing that unique_id > retrieved from SSL is binary but not this one. Apparently when he > implemented it in 2.2, Tim expected it to be used only with IDs > produced on the output which are already strings (very likely in > a similar way to the HTTP unique ID we can generate), in order > to pass it into logs. But the protocol's doc says it's an opaque > byte sequence: > > The value of the type PP2_TYPE_UNIQUE_ID is an opaque byte sequence of > up to 128 bytes generated by the upstream proxy that uniquely identifies > the connection. > > But if we change it now to support binary, then it will be logged as > a hex string and can break some setups. OK that explains it. I was following PROXY2 spec so I simply and happily sent out the TLV as I wished. :-) > > I'm seeing three possibilities short-term for you: > - you just patch the code for now to try again: This patch was not enough; the behavior was exactly the same. On a brief inspection of the relevant code, and considering my unfamiliarity with it, I couldn't immediately solve it. So I left it out to try the other suggestions, which would certainly work. > > - we could create a new sample fetch function for the binary mode, > such as fc_pp_unique_id_raw(), and be done with that. We'd then > add a reference to it in the doc of the existing one. That could be good to keep very close to the spec and avoid a future case like this. Plus, it would be quite explicit having the _raw suffix. > > - your application doesn't need at all to emit non-printable > bytes and you can adjust the contents (of base64/hex them). This one would work for sure, and it did. :-) The impact is pretty much minimal, so for now it's the most sensible road. It could be worthwhile to have fc_pp_unique_id_raw for completeness but I understand it can be troublesome when logging things. > > 3- Of least importance and not really a question: I couldn't use > > symbolic names in the conf (e.g.: neither UNIQUE_ID or > > PP2_TYPE_UNIQUE_ID[1]; it is not clear to me which should be used and > > HAProxy complains about either). > > I must confess I don't know either but wouldn't be surprised that it > doesn't decode such names. If so, that's too bad, because they don't > change often and being able to resolve them would make confs so much > more readable. > > If you (or someone else) has 15mn to spend on a patch for this, I'd > happily apply it! It might be an interesting route in order to get more familiar with the relevant code, but I can't promise at the moment. :-) As always, thank you very much for taking the time to explain things and suggest very workable solutions! Best regards,
