Hi, > Thanks to all your tests and observations, I managed to spot the bug and to > fix it. The headers are linked in a list whose tail is known as hdr_idx->tail. > This pointer is used when adding new headers. Unfortunately the header > removal > function did not update it when it removed the last header. The effect is that > when adding the x-forwarded-for header, it's added just after the previously > removed Connection header so it does not appear in the list when walked from > the beginning. It's really when you said that it broke when Connection was > the last header that I understood what to look for. Thanks ! I've confirmed it's working fine now, and successfully deployed the new version yesterday in our live environment. Many thanks for fixing it! :)
Sidenote to list-readers: Do not use stunnel with the out-of-tree x-forwarded-for patch for SSL termination if you want to balance based on that header with two haproxy frontends and one backend. Stunnel will add an additional X-Forwarded-For header even if your clients send one. >> Expected behaviour: >> Case a) should not jump between servers. An empty x-forwarded-for header >> means that always the "same" header (an empty one) should be hashed, you >> should always end up on the same server. > > This is not true in haproxy, and there is an explicit test for this. If you > try to hash on an empty or non-existing header or parameter, then it falls > back to round robin. This is very important because there are many conditions > where you want to optimize stickiness when the information is present, but > not send all visitors to the same random server if they don't have the info. > Oh right, it really has to be like that! That was just a (too) quick thought and I was misleaded... Well thanks again for this great piece of software! :) Best regards, Craig
