Skip to content

Commit b3d30f4

Browse files
authored
https_client: trigger connection reset timer on HTTP/2 and send/recv errors, not just timeouts
We saw recurring "curl request failed with 16: Error" (CURLE_HTTP2) and "curl request failed with 55: Error / Send failure: Broken pipe" (CURLE_SEND_ERROR) on a production OpenWrt router running two https-dns-proxy instances, even after tuning max_idle_time down to 30s. These are classic symptoms of curl reusing a stale/half-closed HTTP/2 connection - the same class of problem the existing reset_timer/https_client_reset mechanism was built to recover from, but that mechanism is currently only armed on CURLE_OPERATION_TIMEDOUT. HTTP/2 stream errors and send/recv errors on a reused connection never reach it, so the proxy keeps trying to reuse a bad connection indefinitely instead of forcing a fresh one. This extends the existing case in https_fetch_ctx_process_response() to also arm the reset timer for CURLE_HTTP2, CURLE_HTTP2_STREAM, CURLE_GOT_NOTHING, and CURLE_SEND_ERROR - all indicators of a broken/stale connection rather than a one-off content error. No new mechanism is introduced; this only widens the set of error codes that trigger the recovery path that already exists. Tested on a production OpenWrt router (two instances, Cloudflare + Quad9 backends) - confirmed the reset timer now arms and fires (full client reset) in response to these errors, where previously they were silently ignored.
1 parent 0305226 commit b3d30f4

1 file changed

Lines changed: 6 additions & 0 deletions

File tree

src/https_client.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -357,6 +357,12 @@ static int https_fetch_ctx_process_response(https_client_t *client,
357357
WLOG_REQ("curl request failed with write error (probably response content was too large)");
358358
break;
359359
case CURLE_OPERATION_TIMEDOUT:
360+
case CURLE_HTTP2:
361+
case CURLE_HTTP2_STREAM:
362+
case CURLE_GOT_NOTHING:
363+
case CURLE_SEND_ERROR:
364+
// These all indicate a stale/broken (often reused HTTP/2) connection,
365+
// not a one-off content error - same recovery path as a timeout.
360366
if (!ev_is_active(&client->reset_timer)) {
361367
ILOG_REQ("Client reset timer started");
362368
ev_timer_start(client->loop, &client->reset_timer);

0 commit comments

Comments
 (0)