tree 299bc433ac97f4f25ada7fbca55157be374d51aa
parent 8e6c6611e8b03bebc9d19be0b466a8b1104e820d
author Frédéric Lécaille <flecaille@haproxy.com> 1679480985 +0100
committer Frédéric Lécaille <flecaille@haproxy.com> 1680249299 +0200

BUG/MINOR: quic: Missing max_idle_timeout initialization for the connection

This bug was revealed by handshakeloss interop tests (often with quiceh) where one
could see haproxy an Initial packet without TLS ClientHello message (only a padded
PING frame). In this case, as the ->max_idle_timeout was not initialized, the
connection was closed about three seconds later, and haproxy opened a new one with
a new source connection ID upon receipt of the next client Initial packet. As the
interop runner count the number of source connection ID used by the server to check
there were exactly 50 such IDs used by the server, it considered the test as failed.

So, the ->max_idle_timeout of the connection must be at least initialized
to the local "max_idle_timeout" transport parameter value to avoid such
a situation (closing connections too soon) until it is "negotiated" with the
client when receiving its TLS ClientHello message.

Must be backported to 2.7 and 2.6.