A full run of the suite caught srv_conn() reporting zero where the test
expects one. The server closed its connection as soon as it had
answered, and when that close reached haproxy before the response rules
were evaluated, the server connection was already released and the
counter had gone back to zero.
The server now holds its connection until the client has read the
response, which is necessarily after the rules have run.
# A single thread is used because act_conn and fe_conn are over-counted
# when several threads accept in parallel on a loaded machine, which
# would make the connection counters below unpredictable.
+#
+# The server holds its connection until the client has read the response
+# because srv_conn() counts the established connections: if the server
+# closed as soon as it answered, its connection could be released before
+# the response rules run and the counter would be read as zero.
feature ignore_unknown_macro
+barrier b1 cond 2
+
server s1 {
rxreq
txresp
+ barrier b1 sync
} -start
haproxy h1 -conf {
client c1 -connect ${h1_fe_sock} {
txreq
rxresp
+ barrier b1 sync
expect resp.status == 200
expect resp.http.x-feid == "11"