Aurélien D.

Hi @dragosrp, >multiple log entries for same request The reason why you're getting the same request logged twice is because your `https-in` frontend proxy is first inheriting from defaults proxy...

>Not garbled/transformed data with # These `#char` escapes come from the `%hr` format string which automatically encodes the capture (note that this is not the case with `%{+Q}[capture.req.hdr(0)]`). I don't...

Now for the last point (I hope I don't forget anything): ``` No. What is even weird is that if I put declare capture request len 100 http-request capture req.body...

> Instead of %{+Q}r there is the body encoded with #char escapes, see? > Nov 8 17:22:27 localhost haproxy[2775558]: 139.59.147.204:55714 [08/Nov/2023:17:22:27.149] https-in~ something/somethingelse1-5 0/0/1/11/12 404 192 - - ---- 17/17/0/0/0...

It's a good thing you were able to upgrade to 2.6.15, thanks! As you pointed out, your issue might indeed be related to peers since the spinning loop report mentions...

Ok, it makes sense indeed. >as a last measurement we deployed 2.8.4 to all the HAProxies which stopped the crashes. Whether this bug still exist in that version or not...

Great, thanks for letting us know! :) FYI, another similar peers related bug affecting 2.8 was discovered very recently (#2373), but hopefully you don't seem to be triggering it. Anyway,...

Unfortunately `timeout server` which can be configured using the `timeout` setting from httpclient request doesn't affect the timeout used to establish the initial TCP connection. The timeout server is used...

Hi, Thanks for the report I think I'm able to reproduce this using h2load on 2.4+ (behavior slightly differs on 2.2), can't confirm if this is expected behavior or not....

Ok, thanks for confirming