Found while investigating #605. Minor robustness gap: a connection stuck in the TLS handshake is reaped only by --max-time, never by the per-slot --timeout.
In back_wait the per-slot timeout runs only when the local gestion_timeout flag is armed (htsback.c). That flag is set by the CONNECTING, WAIT_DNS and receiving handlers, but the STATUS_SSL_WAIT_HANDSHAKE handler sets neither it nor timeout_refresh. So when the only in-flight slots are stuck mid-handshake (peer completed the TCP connect but never finishes the TLS handshake), the per-slot timeout loop is skipped and SSL_connect keeps returning WANT_READ until --max-time fires.
Confirmed on POSIX: against a server that accepts the TCP connect and never starts the TLS handshake, --timeout=3 did not interrupt it and the crawl ran until --max-time.
Fix: arm gestion_timeout in the STATUS_SSL_WAIT_HANDSHAKE handler (and refresh timeout_refresh on entry). The existing generic check already reaps any status > 0 slot once armed.
Found while investigating #605. Minor robustness gap: a connection stuck in the TLS handshake is reaped only by
--max-time, never by the per-slot--timeout.In
back_waitthe per-slot timeout runs only when the localgestion_timeoutflag is armed (htsback.c). That flag is set by the CONNECTING, WAIT_DNS and receiving handlers, but theSTATUS_SSL_WAIT_HANDSHAKEhandler sets neither it nortimeout_refresh. So when the only in-flight slots are stuck mid-handshake (peer completed the TCP connect but never finishes the TLS handshake), the per-slot timeout loop is skipped andSSL_connectkeeps returning WANT_READ until--max-timefires.Confirmed on POSIX: against a server that accepts the TCP connect and never starts the TLS handshake,
--timeout=3did not interrupt it and the crawl ran until--max-time.Fix: arm
gestion_timeoutin theSTATUS_SSL_WAIT_HANDSHAKEhandler (and refreshtimeout_refreshon entry). The existing generic check already reaps anystatus > 0slot once armed.