FYI: git issues with libcurl 8.0/1 HTTPS push

FYI: git issues with libcurl 8.0/1 HTTPS push

[Daniel Stenberg]

Hello friends.

If you use git with libcurl 8.0.x or 8.1.x, there is a risk that you will 
experience a "curl 56 HTTP/2 stream N was reset" errors when pushing over 
HTTPS. (where N is an odd number, often 7)

This is an unfortunate bug in libcurl that has subsequently already been 
fixed. We recommend using libcurl 8.2.1 (or later).

You can work around this issue (that tends to be sticky) by forcing git to use 
HTTP/1.1 instead of HTTP/2 for the push and then restore back to the previous 
state again.

This bug was filed and has been discussed in this curl issue:

   https://github.com/curl/curl/issues/11353

I'm sorry for this incovenience.

-- 

  / daniel.haxx.se

Re: FYI: git issues with libcurl 8.0/1 HTTPS push

[Junio C Hamano]

Daniel Stenberg <daniel@haxx.se> writes:

> If you use git with libcurl 8.0.x or 8.1.x, there is a risk that you
> will experience a "curl 56 HTTP/2 stream N was reset" errors when
> pushing over HTTPS. (where N is an odd number, often 7)
>
> This is an unfortunate bug in libcurl that has subsequently already
> been fixed. We recommend using libcurl 8.2.1 (or later).
>
> You can work around this issue (that tends to be sticky) by forcing
> git to use HTTP/1.1 instead of HTTP/2 for the push and then restore
> back to the previous state again.

Thanks for a heads-up.

The following is admittedly a very blunt workaround to disable
HTTP/2 for the affected versions for any purpose, but I wonder if it
is an acceptable workaround.  The remote-curl transport helper is
used for both push and fetch and I didn't find a good place to
automatically force the protocol version only for pushes.

 git-curl-compat.h | 12 ++++++++++++
 http.c            |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git c/git-curl-compat.h w/git-curl-compat.h
index fd96b3cdff..f253408288 100644
--- c/git-curl-compat.h
+++ w/git-curl-compat.h
@@ -134,4 +134,16 @@
 #define GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR 1
 #endif
 
+/**
+ * If you use git with libcurl 8.0.x or 8.1.x, there is a risk that
+ * you will experience a "curl 56 HTTP/2 stream N was reset" errors
+ * when pushing over HTTPS. (where N is an odd number, often 7)
+ *
+ * This is an unfortunate bug in libcurl that has subsequently already
+ * been fixed. We recommend using libcurl 8.2.1 (or later).
+ */
+#if (LIBCURL_VERSION_NUM >= 0x080000) && (LIBCURL_VERSION_NUM < 0x080201)
+#define GIT_CURL_AVOID_HTTP2 1
+#endif
+
 #endif
diff --git c/http.c w/http.c
index e138b4b96f..156d6236da 100644
--- c/http.c
+++ w/http.c
@@ -962,7 +962,7 @@ static CURL *get_curl_handle(void)
 		curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);
 	}
 
-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2
+#if defined(GIT_CURL_HAVE_CURL_HTTP_VERSION_2) && !defined(GIT_CURL_AVOID_HTTP2)
     if (curl_http_version) {
 		long opt;
 		if (!get_curl_http_version_opt(curl_http_version, &opt)) {

Re: FYI: git issues with libcurl 8.0/1 HTTPS push

[Daniel Stenberg]

On Tue, 22 Aug 2023, Junio C Hamano wrote:

> The following is admittedly a very blunt workaround to disable HTTP/2 for 
> the affected versions for any purpose, but I wonder if it is an acceptable 
> workaround.  The remote-curl transport helper is used for both push and 
> fetch and I didn't find a good place to automatically force the protocol 
> version only for pushes.

The downside with this approach is that you make it build-time. Since libcurl 
8.2.x is binary compatible with the previous versions, users could easily 
upgrade to a newer libcurl without rebuilding git and then unnecessarily have 
the avoid-h2 code still used.

The ideal approach would do the check in run-time to avoid that.

Wether the problem is serious enough to actually warrant such a work-around in 
the first place, I really cannot say.

-- 

  / daniel.haxx.se

Re: FYI: git issues with libcurl 8.0/1 HTTPS push

[Junio C Hamano]

Daniel Stenberg <daniel@haxx.se> writes:

> The downside with this approach is that you make it build-time. Since
> libcurl 8.2.x is binary compatible with the previous versions, users
> could easily upgrade to a newer libcurl without rebuilding git and
> then unnecessarily have the avoid-h2 code still used.
>
> The ideal approach would do the check in run-time to avoid that.

True.  I however suspect that the ship has already sailed for our
use of libcurl with how git-curl-compat.h uses LIBCURL_VERSION_NUM
for other things already.  A binary of Git built with older libcurl
versions would have compiled out certain features and would still
work with newer libcurl.

Thanks.