Re: [PATCH] ci: work around Debian 12's HTTP/2 authentication failures

From: Jeff King <peff@peff.net>
Date: Sep 23, 2026, 16:47 UTC
Message-ID: <20260923164700.GA28538@coredump.intra.peff.net>
In-Reply-To: <pull.2236.git.1790118373340.gitgitgadget@gmail.com>

On Tue, Sep 22, 2026 at 11:06:13PM +0000, Johannes Schindelin via GitGitGadget wrote:

Show 10 quoted lines

> Anonymous discovery succeeds, but the upload-pack POST requires
> authentication. Apache can return an early 401 and close the HTTP/2
> stream before libcurl finishes sending the request body. Debian 12's
> curl 7.88.1 treats that closure as a transport error instead of allowing
> an authentication retry. Curl fixed this handling in 331b89a319d0
> (http2: polish things around POST), included in 8.3.0:
> https://github.com/curl/curl/pull/11756
> 
> This did not happen before switching to Debian 12 because Debian 11
> ships with libcurl 7.74.0-1.3+deb11u16, which does not have that bug.

Thanks for finding and fixing. I saw this yesterday but hadn't had time to dig in yet, and your explanation is very satisfying. :)

Show 5 quoted lines

> Replacing the packaged libcurl with a modern build would defeat this
> job's purpose of testing older supported distributions. So let's simply
> exclude the flaky t5559.15 and its dependent t5559.16 on Debian 12 until
> the packaged curl carries the fix (or until the end of time, whichever
> comes first).

That should reduce the immediate CI pain, though I can think of two downsides:

  - we're detecting based on CI job name, not on the presence of the
    known bug. So it won't help anybody running the tests themselves
    (even people on debian-12!)

  - we're relying on test numbering, which can change over time. So if
    we add new setup tests early in t5559 (actually, t5551 which it's
    based on!) these will silently go out of sync.

So an ideal solution to me would be more like t5559 checking for the buggy version itself, setting a prereq, and then marking the tests with !HAVE_CURL_HTTP2_BUG.

That said, I'm not sure how tricky that would be to implement. We give the curl version with "git version --build-options", but we'd have to do some version number comparisons. It might not be worth spending a lot of time on this.

-Peff