]> git.kaiwu.me - haproxy.git/commit
REGTEST: ocsp: make the ocsp_client_check test fast
authorWilly Tarreau <w@1wt.eu>
Tue, 10 Nov 2026 09:11:07 +0000 (10:11 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 10 Nov 2026 10:02:23 +0000 (11:02 +0100)
commit85aa5fe935587bcdac3dbb135b2ffb7fdec3cbb5
tree9deefcad198c1004dcebfe254a73b14e90bd6824
parent66e4be2fd0b47948b232f4a720fc8a9ac0ad8fb3
REGTEST: ocsp: make the ocsp_client_check test fast

The last part of the test, which checks what happens when the OCSP
responder is not running anymore, used to take about 3 seconds: the
connection to the responder is refused, and the httpclient performs its
retries with the usual 1 second delay before reporting the responder as
unreachable.

A previous attempt tried to split the test in two but it failed due to
the need to hard-code the listening port which appears in the certificate,
preventing the tests from running in parallel, so everything must remain
in the same file to remain sequential.

In addition, setting a shorter timeout in HAPROXY_TEST_TIMEOUT (e.g. 400)
made it systematically fail with a 504: the 'do-ocsp-request' action limits
the OCSP check to the http-request timeout, which it arms when the rule is
evaluated, while the server timeout of the clear listener which forwards
the client's request was started earlier. Both being set to the same value,
the listener always gave up first.

Let's perform this last check through a dedicated SSL frontend whose
http-request timeout is set to a fixed 50ms, which is the timeout being
tested and remains well below the clear listener's server timeout. The
other checks keep using HAPROXY_TEST_TIMEOUT, so that a real OCSP round
trip is never limited to 50ms. The whole check now reports a timeout,
whose code and reason are verified, and the whole test takes about 700ms
in multiple tests of 250ms each, instead of around 3.2s.
reg-tests/ssl/ocsp_client_check.vtci