# FYI: git issues with libcurl 8.0/1 HTTPS push 4 messages from 2023-08-22 to 2023-08-22. Participants: Daniel Stenberg, Junio C Hamano. Thread: https://gitlist.dev/t/60145 ## Daniel Stenberg, 2023-08-22 11:32 Subject: FYI: git issues with libcurl 8.0/1 HTTPS push Message-ID: URL: https://gitlist.dev/e/qq3252n1-o71-n1r7-281p-npqo6rs5o50%40unkk.fr ``` 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 ``` ## Junio C Hamano, 2023-08-22 16:27 Subject: Re: FYI: git issues with libcurl 8.0/1 HTTPS push Message-ID: URL: https://gitlist.dev/e/xmqq7cpnm48k.fsf%40gitster.g In-Reply-To: ``` Daniel Stenberg 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)) { ``` ## Daniel Stenberg, 2023-08-22 16:42 Subject: Re: FYI: git issues with libcurl 8.0/1 HTTPS push Message-ID: <4q22785-1qr2-824o-806r-26srs4r8p34@unkk.fr> URL: https://gitlist.dev/e/4q22785-1qr2-824o-806r-26srs4r8p34%40unkk.fr In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2023-08-22 16:59 Subject: Re: FYI: git issues with libcurl 8.0/1 HTTPS push Message-ID: URL: https://gitlist.dev/e/xmqq1qfvm2rx.fsf%40gitster.g In-Reply-To: <4q22785-1qr2-824o-806r-26srs4r8p34@unkk.fr> ``` Daniel Stenberg 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. ```