mod_http2: RST_STREAM an incomplete response on the legacy c2 path

On builds without AP_HAS_RESPONSE_BUCKETS (httpd 2.4.x), the h2 worker
runs the c2 connection through h2_c2_process()/c2_process() rather than
the generic ap_process_connection(). c2_process() closes the output beam
unconditionally when the handler returns, so a response that started but
never finished (no EOS, e.g. a CGI that hits the server Timeout
mid-body) leaves a closed beam that h2_beam_is_complete() reports as
complete. s_c2_done() then sends no reset, and stream_data_cb()'s reset
fires only on a c1 re-dispatch that is lost under load, so the stream is
parked and a client without a stall timeout hangs.

When c2_process() finishes with a final response started but no EOS seen
(response_eos_seen, from the preceding commit), abort the output beam
instead of closing it; an aborted beam returns APR_ECONNABORTED from
h2_beam_receive() on the next pull, so the reset fires regardless of the
wakeup. Header-only responses (204/304, and HEAD) are marked complete on
this path too (h2_c2_filter.c) so they are not aborted.

Adds test_h2_105_20: a CGI that goes silent past Timeout, run as
concurrent streams, must be reset.

Author: mmontalbo

modules/http2/h2_c2.c

@@ -824,7 +824,20 @@ static apr_status_t c2_process(h2_conn_ctx_t *conn_ctx, conn_rec *c)
      * request pool may have been deleted. */
     r = NULL;
     if (conn_ctx->beam_out) {
-        h2_beam_close(conn_ctx->beam_out, c);
+        if (conn_ctx->has_final_response && !conn_ctx->response_eos_seen) {
+            /* A final response was started but never completed (no EOS), e.g.
+             * the CGI/handler timed out mid-body. Abort the output beam so the
+             * HTTP/2 stream is RST_STREAM'd. Otherwise s_c2_done() sees the closed
+             * beam as a complete response, sends no reset, and the client is left
+             * waiting for data/EOS that never arrive. Header-only responses
+             * (204/304/HEAD) are marked complete earlier (see the
+             * AP_STATUS_IS_HEADER_ONLY handling) so they are NOT aborted here;
+             * aborting them would re-open PR 69580. */
+            h2_beam_abort(conn_ctx->beam_out, c);
+        }
+        else {
+            h2_beam_close(conn_ctx->beam_out, c);
+        }
     }
 
     ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,

modules/http2/h2_c2_filter.c

@@ -549,6 +549,12 @@ static apr_status_t pass_response(h2_conn_ctx_t *conn_ctx, ap_filter_t *f,
 
     if (response->status >= HTTP_OK) {
         conn_ctx->has_final_response = 1;
+        if (AP_STATUS_IS_HEADER_ONLY(response->status)) {
+            /* A header-only response (204/304) is complete without a body
+             * EOS; mark it complete so c2_process() does not abort/reset it as
+             * an "incomplete" response (which would re-open PR 69580). */
+            conn_ctx->response_eos_seen = 1;
+        }
     }
     ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, parser->c,
                   APLOGNO(03197) "h2_c2(%s): passed response %d",
@@ -757,6 +763,10 @@ apr_status_t h2_c2_filter_response_out(ap_filter_t *f, apr_bucket_brigade *bb)
     }
 
     if (r->header_only || AP_STATUS_IS_HEADER_ONLY(r->status)) {
+        /* A header-only response (HEAD, or 204/304) is complete without a body
+         * EOS; mark it complete so c2_process() does not abort/reset it as an
+         * "incomplete" response (which would re-open PR 69580). */
+        conn_ctx->response_eos_seen = 1;
         ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, f->c,
                       "h2_c2(%s): headers only, cleanup output brigade", conn_ctx->id);
         b = body_bucket? body_bucket : APR_BRIGADE_FIRST(bb);

test/modules/http2/htdocs/cgi/h2cgi_slow.py

@@ -0,0 +1,13 @@
+#!/usr/bin/env python3
+# Start a response (status + headers + a little body), then go silent for
+# longer than the server's `Timeout`. Over HTTP/2 this makes Apache's content
+# filter time out reading from the CGI (AH01220): the response was started but
+# never completed (no EOS). A correct server RST_STREAMs the stream; a buggy
+# one leaves the client hanging. Used by test_105_timeout.py.
+import sys
+import time
+
+sys.stdout.write("Content-Type: application/octet-stream\r\n\r\n")
+sys.stdout.write("X" * 16384)
+sys.stdout.flush()
+time.sleep(30)

test/modules/http2/test_105_timeout.py

@@ -166,7 +166,55 @@ def test_h2_105_12(self, env):
         assert piper.response, f'{piper}'
         assert piper.response['status'] == 408, f"{piper.response}"
 
-    # A body-less response that is missing an EOS
+    # A CGI that starts a response (status + headers + some body) and then goes
+    # silent past `Timeout` must lead to the HTTP/2 stream being RST_STREAM'd,
+    # not leave the client hanging. Regression test for the mod_http2 hang where
+    # a c2 that finished an *incomplete* response (no EOS, e.g. CGI timed out
+    # mid-body) was treated as complete and no reset was ever sent.
+    def test_h2_105_20(self, env):
+        conf = H2Conf(env)
+        conf.add("Timeout 1")
+        conf.add("PassEnv PATH")  # let the CGI find its interpreter
+        conf.add_vhost_cgi()
+        conf.install()
+        assert env.apache_restart() == 0
+        url = env.mkurl("https", "cgi", "/h2cgi_slow.py")
+        # Open many streams at once on ONE h2 connection. A correct server
+        # RST_STREAMs every silent CGI, so the whole batch finishes in ~Timeout.
+        # A buggy server fails to reset at least one of them (the missed reset is
+        # racy per-stream, but with many streams in flight it is reliably hit),
+        # so curl --parallel waits until its --max-time. Key on elapsed time, not
+        # exit code: --parallel makes the exit code ambiguous, and a hang here is
+        # a multi-second stall versus a sub-second clean teardown. --max-time
+        # also bounds the client so a hang cannot wedge the test.
+        #
+        # Why 10 streams: a single silent stream hangs only racily (about 80%),
+        # and the racy/deterministic knee is sharp. A sweep on a fast idle box
+        # measured 80% hang at 1 to 2 streams but 100% at 3 or more (1 and 2 are
+        # equally racy because the streams are correlated under one session
+        # connection, so it is a threshold, not an independent-probability
+        # curve). The knee rises on faster or less-loaded machines (the server
+        # wins the per-stream reset race more often), so 10 keeps a wide margin
+        # for CI hardware variance. The streams are concurrent, so the larger
+        # count costs no wall-clock, and 10 is well under the default 100 max
+        # concurrent streams.
+        count = 10
+        max_time = 10
+        r = env.curl_raw([url] * count, options=[
+            "--parallel", "--parallel-immediate", "--max-time", str(max_time)])
+        assert r.duration < timedelta(seconds=max_time - 2), \
+            f'streams hung waiting for RST_STREAM (batch took {r.duration}): {r}'
+        # Resetting each silent CGI is logged as a CGI timeout (cgid) and the
+        # failed body read that follows it (core); both are expected here.
+        time.sleep(1)  # let the log flush
+        env.httpd_error_log.ignore_recent(
+            lognos = [
+                "AH01220",  # cgid: Timeout waiting for output from CGI script
+                "AH00574",  # core: ap_content_length_filter, apr_bucket_read() failed
+            ]
+        )
+
+    # Complement to test_h2_105_20: a body-less response that is missing an EOS
     # must NOT be reset over HTTP/2. mod_cache revalidation of a cached,
     # immediately-stale resource emits exactly such a 304 (EOR + Flush, no EOS).
     # This guards the incomplete-response reset against re-opening PR 69580: