[pigri]

h2_idle_timeout is the only thing that closes a downstream HTTP/2
connection with no streams in flight, and it cannot distinguish the two
situations that produce that state.

A connection that has served requests and is being held open for the next
one is worth keeping: closing it costs a fresh TCP and TLS handshake. HTTP/2
clients also keep channels warm with PINGs, which open no stream, so by this
measure a healthy warm channel looks idle and is reaped on the same timer.

Raising the timeout to accommodate that is the obvious response, and it
silently raises how long a connection that completed the handshake and never
opened a single stream can hold a file descriptor. ActiveSessions reports a
count of zero for both cases, and nothing else in the accept loop reaps such
a connection — so tuning for the first case loosens the second by the same
factor, with no way to opt out.

Change

The two periods get their own bounds:

pub struct IdleReaping {
    /// Applies once the connection has carried at least one stream.
    pub idle: Option<Duration>,
    /// Applies until the first stream is accepted. `None` falls back to `idle`.
    pub first_stream: Option<Duration>,
}

surfaced as h2_first_stream_timeout alongside h2_idle_timeout on
HttpServerOptions.

• No behaviour change unless the new option is set. first_stream
  unset falls back to idle, which is exactly what the accept loop did
  before, and IdleReaping::uniform expresses that at call sites.
• A codec-rejected stream neither promotes the connection nor buys it
  time. Answering a protocol error is not evidence the connection is
  being used. The first-stream bound is therefore a deadline fixed at the
  start of the connection, not a period: tokio::select! rebuilds its
  futures each iteration and a rejected stream is a continue, so a
  duration here would restart on every rejection — at a 10s bound, roughly
  310s of lifetime before the malformed-stream budget intervenes. The
  post-first-stream bound stays a restarting period, which is what makes
  keepalive worth having.
• The durations are passed as a struct rather than as two adjacent
  Option<Duration> parameters, which would be silently swappable at every
  call site.

Tests

Two, each failing for its own reason:

• test_h2_first_stream_timeout_closes_a_connection_that_opens_nothing —
  the idle bound is set an order of magnitude longer than the test's own
  ceiling, so passing can only mean the first-stream bound did the work.

• test_h2_first_stream_timeout_stops_applying_once_a_stream_is_carried —
  the control. Without it, a regression that applied the short bound
  unconditionally would close every keepalive connection between requests
  and the first test would still pass.

• test_h2_first_stream_timeout_is_not_restarted_by_a_rejected_stream —
  repeated conflicting-Content-Length streams, which h2 passes through to
  be reset at the stream level. Worth noting that the obvious route, a
  control byte in :path, is caught inside h2 and never reaches the accept
  loop, so a test built on it passes while exercising nothing.

Verified by mutation rather than by reading: making first_stream fall
through to idle, treating every connection as having carried a stream,
treating none as having done so, and re-arming the deadline per iteration
each fail the corresponding test and only that test.

cargo clippy --all-targets -- --deny warnings and the pingora-core lib
suite are clean (626 pass). connectors::l4::tests::test_conn_error_addr_not_avail
fails identically on unmodified main in this environment and is unrelated.

[linear-code]

SYN-348