Hi,
I noticed that GitLab's CI started to fail consistently with our
Alpine-based builds in t5559.30. After investigating a bit I couldn't
notice anything obvious on our side changing, so I checked whether
Alpine itself updated any packages. And indeed, it updated to curl 8.10
yesterday.
I first expected this to be musl-specific, but I can reproduce the issue
on my glibc system, as well. The issue bisects to 35bf76628 (http2:
improved upload eos handling, 2024-08-04), which checks out with the
symptoms.
Reproducer in the Git project:
```
$ make
$ cd t/
$ ./t5559-http-fetch-smart-http2.sh --run=1-4,30 -ix
```
Apache logs:
[Fri Sep 13 05:10:57.153872 2024] [ssl:warn] [pid 1435033:tid 1435033] AH01909: dummy:443:0 server certificate does NOT include an ID which matches the server name
[Fri Sep 13 05:10:57.156090 2024] [ssl:warn] [pid 1435035:tid 1435035] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache]
[Fri Sep 13 05:10:57.157052 2024] [ssl:warn] [pid 1435035:tid 1435035] AH01909: dummy:443:0 server certificate does NOT include an ID which matches the server name
[Fri Sep 13 05:10:57.158122 2024] [mpm_event:notice] [pid 1435035:tid 1435035] AH00489: Apache/2.4.62 (Unix) OpenSSL/3.0.14 configured -- resuming normal operations
[Fri Sep 13 05:10:57.158140 2024] [core:notice] [pid 1435035:tid 1435035] AH00094: Command line: '/nix/store/r2vzwkm8xvzdkfyqc9m3b3cc6q6jdly4-apache-httpd-2.4.62/bin/httpd -d /tmp/git-tests/trash directory.t5559-http-fetch-smart-http2/httpd -f /home/pks/Development/git/t/lib-httpd/apache.conf -D HTTP2 -D SSL -c Listen 127.0.0.1:5559'
[Fri Sep 13 05:11:57.434888 2024] [cgi:error] [pid 1435039:tid 1435046] (70007)The timeout specified has expired: [remote 127.0.0.1:53154] AH01225: Error reading request entity data
[Fri Sep 13 05:11:57.545789 2024] [mpm_event:notice] [pid 1435035:tid 1435035] AH00491: caught SIGTERM, shutting down
Most lines are expected, but the second-to-last line mentions an expired
timeout. So I suspect that with the mentioned commit, curl does not
detect the EOS correctly in all scenarios anymore. This only happens
with HTTP/2 -- the tests continue to work just fine with HTTP/1, which
we execute via t5551.
I didn't dig much further than that.
Patrick
