Hello Baptiste,
On 26 February 2018 at 16:04, Baptiste <bed...@gmail.com> wrote: > Your use case is right and I perfectly understand it and it makes sense to > me. > that said, in my use case, I was using (and meaning) SRV records and using > consul / kubernetes as backend servers. > What I saw is that when the response is too big, the server will send only > the SRV records with TC flag and no "ADDITIONAL" section. So in such case, > it was still acceptable for HAProxy. I see, that makes sense. But still when your actual SRV records grow beyond the 1280 byte limit, you would hit the very same issue. > According to you, what would be the best option: > - entirely remove this "feature" and consider the admins know what they do > (I include the copy/paste admins that simply copy content of different blog > articles until "it works") > - enable this feature for a single "retry" of the same query? (that would > happen after we did a retry with a different query type) Honestly, as long as we don't have proper TC handling with TCP support, I think it makes more sense to remove it entirely. Yes, downgrading only for the next retry, adding counters and making the downgrade optional really helps to mitigate the mentioned issues; but when I consider that the benefit only affects a certain response size that can't be too big (so that it fits without the ADDITIONAL section), then I don't think it's worth it. Imho it makes more sense to remove this in 1.8 and work towards full TCP support on TC in 1.9. But, that is not a strong opinion, it's rather what I would personally do, also considering the effort that has to be put into TCP support. As long as we don't downgrade by default, I am OK with it. Thanks, Lukas
