From: Willy Tarreau <w@1wt.eu>
Date: Tue, 22 Sep 2026 22:50:12 +0000 (+0000)
Subject: REGTESTS: converter: serve the two sha2 requests on one connection
X-Git-Tag: v3.5-dev8~7
X-Git-Url: https://git.kaiwu.me/?a=commitdiff_plain;h=26dd5a488038a76e3c398d7d67542bfd6ffbc88b;p=haproxy.git

REGTESTS: converter: serve the two sha2 requests on one connection

The final validation campaign caught this test with "HTTP header is
incomplete" when the whole suite runs with "--j 32" on a loaded
machine. Its client sends its two requests over a single connection
while the server answers each of them in its own iteration, so it
closes after the first response, exactly when the second request is
sent over the connection haproxy reuses, and the client gets that close
instead of a response.

This is the same shape which was fixed in the transaction state test:
the server now keeps its connection for both requests. Twenty runs in
parallel with the machine loaded pass.
---

diff --git a/reg-tests/converter/sha2.vtc b/reg-tests/converter/sha2.vtc
index da7557f75..954aa5944 100644
--- a/reg-tests/converter/sha2.vtc
+++ b/reg-tests/converter/sha2.vtc
@@ -4,16 +4,25 @@ feature cmd "$HAPROXY_PROGRAM -cc 'feature(OPENSSL)'"
 
 feature ignore_unknown_macro
 
+# Both requests of the client below travel on the same connection, so
+# the server keeps its own connection open for the two of them. Serving
+# them in two iterations would close it after the first response, right
+# when the second request is sent over the connection haproxy reuses,
+# and the client would get a close instead of a response.
 server s1 {
 	rxreq
 	txresp
-} -repeat 2 -start
+
+	rxreq
+	txresp
+} -start
 
 haproxy h1 -conf {
     global
     .if feature(THREAD)
         thread-groups 1
     .endif
+        chroot /
 
     defaults
 	mode http