mod_http2: RST_STREAM an incomplete response on the legacy c2 path

On the legacy c2 path, c2_process() always h2_beam_close()d the output
beam when the handler returned. A response whose body never completed,
e.g. a CGI that sent status, headers and a partial body and then timed
out, was closed with no EOS. h2_beam_is_complete() reports such a closed
beam complete, so s_c2_done() sends no reset.

The only remaining reset, stream_data_cb() on APR_EOF, is starved:
h2_beam_receive() returns APR_EOF only on a receive that transfers zero
buckets from a closed beam. The single wakeup at close drives one
receive, which usually transfers the response's trailing flush and
returns APR_SUCCESS, so the stream re-suspends; no further wakeup follows
and it parks, and the client hangs waiting for data that never comes.

Abort the beam instead when a final response was started but never
completed and is not header-only, the same test s_c2_done() applies. An
aborted beam returns APR_ECONNABORTED from the top of h2_beam_receive(),
before the transfer, so the terminal is observed on that one receive
regardless of any trailing buckets. Header-only responses (204/304/HEAD)
are still closed normally; only genuinely truncated responses are reset.

Author: mmontalbo

modules/http2/h2_c2.c

@@ -805,7 +805,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
+            && !h2_beam_is_complete(conn_ctx->beam_out)
+            && !conn_ctx->header_only) {
+            /* A final response was started but its body never completed (no
+             * EOS), e.g. the CGI/handler timed out mid-body. Abort so the
+             * stream is RST_STREAM'd. Closing here would mark the beam complete
+             * and s_c2_done() would see nothing to reset, leaving the client
+             * hanging. Header-only responses (204/304/HEAD) carry no body EOS
+             * and are closed normally, not reset (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,

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

@@ -1,5 +1,6 @@
 import socket
 import time
+from datetime import timedelta
 
 import pytest
 
@@ -165,7 +166,46 @@ 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_vhost_cgi()
+        conf.install()
+        assert env.apache_restart() == 0
+        url = env.mkurl("https", "cgi", "/h2cgi_slow.py")
+        # Open many concurrent streams on one h2 connection. The missed reset
+        # is racy per stream: the single wakeup at close drives one receive,
+        # which resets only if it finds the beam already drained but usually
+        # still carries the response's trailing flush and re-suspends. So one
+        # stream is unreliable while many in flight hang at least one every
+        # run. Key on elapsed time, not curl's exit code (--parallel makes
+        # that ambiguous): a hang is a multi-second stall, a correct reset a
+        # sub-second teardown. --max-time bounds the client so a hang cannot
+        # wedge the test. The per-stream hang is a timing race, so its odds
+        # shift with hardware and load; 10 is cheap margin and, being
+        # concurrent, costs no wall-clock.
+        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: