{"thread":{"id":"60145","subject":"FYI: git issues with libcurl 8.0/1 HTTPS push","startedAt":"2023-08-22T11:48:50Z","lastAt":"2023-08-22T16:59:34Z","messageCount":4,"participants":["Daniel Stenberg","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"480921","messageId":"qq3252n1-o71-n1r7-281p-npqo6rs5o50@unkk.fr","threadId":"60145","inReplyTo":null,"subject":"FYI: git issues with libcurl 8.0/1 HTTPS push","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2023-08-22T11:32:09Z","receivedAt":"2023-08-22T11:48:50Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"Hello friends.\n\nIf you use git with libcurl 8.0.x or 8.1.x, there is a risk that you will \nexperience a \"curl 56 HTTP/2 stream N was reset\" errors when pushing over \nHTTPS. (where N is an odd number, often 7)\n\nThis is an unfortunate bug in libcurl that has subsequently already been \nfixed. We recommend using libcurl 8.2.1 (or later).\n\nYou can work around this issue (that tends to be sticky) by forcing git to use \nHTTP/1.1 instead of HTTP/2 for the push and then restore back to the previous \nstate again.\n\nThis bug was filed and has been discussed in this curl issue:\n\n https://github.com/curl/curl/issues/11353\n\nI'm sorry for this incovenience.\n\n-- \n\n / daniel.haxx.se\n"},{"id":"480928","messageId":"xmqq7cpnm48k.fsf@gitster.g","threadId":"60145","inReplyTo":"qq3252n1-o71-n1r7-281p-npqo6rs5o50@unkk.fr","subject":"Re: FYI: git issues with libcurl 8.0/1 HTTPS push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-22T16:27:55Z","receivedAt":"2023-08-22T16:28:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Stenberg writes:\n\n> If you use git with libcurl 8.0.x or 8.1.x, there is a risk that you\n> will experience a \"curl 56 HTTP/2 stream N was reset\" errors when\n> pushing over HTTPS. (where N is an odd number, often 7)\n>\n> This is an unfortunate bug in libcurl that has subsequently already\n> been fixed. We recommend using libcurl 8.2.1 (or later).\n>\n> You can work around this issue (that tends to be sticky) by forcing\n> git to use HTTP/1.1 instead of HTTP/2 for the push and then restore\n> back to the previous state again.\n\nThanks for a heads-up.\n\nThe following is admittedly a very blunt workaround to disable\nHTTP/2 for the affected versions for any purpose, but I wonder if it\nis an acceptable workaround. The remote-curl transport helper is\nused for both push and fetch and I didn't find a good place to\nautomatically force the protocol version only for pushes.\n\n git-curl-compat.h | 12 ++++++++++++\n http.c | 2 +-\n 2 files changed, 13 insertions(+), 1 deletion(-)\n\ndiff --git c/git-curl-compat.h w/git-curl-compat.h\nindex fd96b3cdff..f253408288 100644\n--- c/git-curl-compat.h\n+++ w/git-curl-compat.h\n@@ -134,4 +134,16 @@\n #define GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR 1\n #endif\n \n+/**\n+ * If you use git with libcurl 8.0.x or 8.1.x, there is a risk that\n+ * you will experience a \"curl 56 HTTP/2 stream N was reset\" errors\n+ * when pushing over HTTPS. (where N is an odd number, often 7)\n+ *\n+ * This is an unfortunate bug in libcurl that has subsequently already\n+ * been fixed. We recommend using libcurl 8.2.1 (or later).\n+ */\n+#if (LIBCURL_VERSION_NUM >= 0x080000) && (LIBCURL_VERSION_NUM < 0x080201)\n+#define GIT_CURL_AVOID_HTTP2 1\n+#endif\n+\n #endif\ndiff --git c/http.c w/http.c\nindex e138b4b96f..156d6236da 100644\n--- c/http.c\n+++ w/http.c\n@@ -962,7 +962,7 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);\n \t}\n \n-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2\n+#if defined(GIT_CURL_HAVE_CURL_HTTP_VERSION_2) && !defined(GIT_CURL_AVOID_HTTP2)\n if (curl_http_version) {\n \t\tlong opt;\n \t\tif (!get_curl_http_version_opt(curl_http_version, &opt)) {\n"},{"id":"480929","messageId":"4q22785-1qr2-824o-806r-26srs4r8p34@unkk.fr","threadId":"60145","inReplyTo":"xmqq7cpnm48k.fsf@gitster.g","subject":"Re: FYI: git issues with libcurl 8.0/1 HTTPS push","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2023-08-22T16:42:55Z","receivedAt":"2023-08-22T16:43:08Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 22 Aug 2023, Junio C Hamano wrote:\n\n> The following is admittedly a very blunt workaround to disable HTTP/2 for \n> the affected versions for any purpose, but I wonder if it is an acceptable \n> workaround. The remote-curl transport helper is used for both push and \n> fetch and I didn't find a good place to automatically force the protocol \n> version only for pushes.\n\nThe downside with this approach is that you make it build-time. Since libcurl \n8.2.x is binary compatible with the previous versions, users could easily \nupgrade to a newer libcurl without rebuilding git and then unnecessarily have \nthe avoid-h2 code still used.\n\nThe ideal approach would do the check in run-time to avoid that.\n\nWether the problem is serious enough to actually warrant such a work-around in \nthe first place, I really cannot say.\n\n-- \n\n / daniel.haxx.se\n"},{"id":"480931","messageId":"xmqq1qfvm2rx.fsf@gitster.g","threadId":"60145","inReplyTo":"4q22785-1qr2-824o-806r-26srs4r8p34@unkk.fr","subject":"Re: FYI: git issues with libcurl 8.0/1 HTTPS push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-22T16:59:30Z","receivedAt":"2023-08-22T16:59:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Stenberg writes:\n\n> The downside with this approach is that you make it build-time. Since\n> libcurl 8.2.x is binary compatible with the previous versions, users\n> could easily upgrade to a newer libcurl without rebuilding git and\n> then unnecessarily have the avoid-h2 code still used.\n>\n> The ideal approach would do the check in run-time to avoid that.\n\nTrue. I however suspect that the ship has already sailed for our\nuse of libcurl with how git-curl-compat.h uses LIBCURL_VERSION_NUM\nfor other things already. A binary of Git built with older libcurl\nversions would have compiled out certain features and would still\nwork with newer libcurl.\n\nThanks.\n"}]}