git/git-curl-compat.h, branch main

http: add support for HTTP 429 rate limit retries

2026-03-17T16:14:19Z

Add retry logic for HTTP 429 (Too Many Requests) responses to handle server-side rate limiting gracefully. When Git's HTTP client receives a 429 response, it can now automatically retry the request after an appropriate delay, respecting the server's rate limits. The implementation supports the RFC-compliant Retry-After header in both delay-seconds (integer) and HTTP-date (RFC 2822) formats. If a past date is provided, Git retries immediately without waiting. Retry behavior is controlled by three new configuration options (http.maxRetries, http.retryAfter, and http.maxRetryTime) which are documented in git-config(1). The retry logic implements a fail-fast approach: if any delay (whether from server header or configuration) exceeds maxRetryTime, Git fails immediately with a clear error message rather than capping the delay. This provides better visibility into rate limiting issues. The implementation includes extensive test coverage for basic retry behavior, Retry-After header formats (integer and HTTP-date), configuration combinations, maxRetryTime limits, invalid header handling, environment variable overrides, and edge cases. Signed-off-by: Vaidas Pilkauskas Signed-off-by: Junio C Hamano

curl: add support for curl_global_trace() components

2025-08-27T16:49:43Z

In addition to the regular trace information produced by CURLOPT_VERBOSE, recent curl versions can enable or disable tracing of specific subsystems using a call to curl_global_trace(). This level of detail may or may not be useful for us in Git as mere users of libcurl, but there's one case where we need it for a test. In t5564, we set up a socks proxy, access it with GIT_TRACE_CURL set, and expect to find socks-related messages in the output. This test is broken in the release candidates for libcurl 8.16, as those socks messages are no longer produced in the trace. The problem bisects to curl's commit ab5e0bfddc (pytest: add SOCKS tests and scoring, 2025-07-21). There the socks messages were moved from generic infof() messages to the component-specific CURL_TRC_CF() system. And so we do not see them by default, but only if "socks" is enabled as a logging component. Teach Git's http code to accept a component list from the environment and pass it into curl_global_trace(). We can then use that in the test to enable the correct component. It should be safe to do so unconditionally. In older versions of curl which don't support this call, setting the environment variable is a noop. Likewise, any versions of curl which don't recognize the "socks" component should silently ignore it. The manpage for curl_global_trace() says this: The config string is a list of comma-separated component names. Names are case-insensitive and unknown names are ignored. The special name "all" applies to all components. Names may be prefixed with '+' or '-' to enable or disable detailed logging for a component. The list of component names is not part of curl's public API. Names may be added or disappear in future versions of libcurl. Since unknown names are silently ignored, outdated log configurations does not cause errors when upgrading libcurl. Given that, some names can be expected to be fairly stable and are listed below for easy reference. So this should let us make the test work on all versions without worrying about confusing older (or newer) versions. For the same reason, I've opted not to document this interface. This is deep internal voodoo for which we can make no promises to users. In fact, I was tempted to simply hard-code "socks" to let our test pass and not expose anything. But I suspect a little run-time flexibility may come in handy in the future when debugging or dealing with similar logging issues. I also considered just putting "all" into such a hard-coded default. But if you try it, you will see that many of the components are quite verbose and likely not interesting. They would clutter up our trace output if we enabled them by default. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

http.c: allow custom TCP keepalive behavior via config

2025-03-21T08:38:52Z

curl supports a few options to control when and how often it should instruct the OS to send TCP keepalives, like KEEPIDLE, KEEPINTVL, and KEEPCNT. Until this point, there hasn't been a way for users to change what values are used for these options, forcing them to rely on curl's defaults. But we do unconditionally enable TCP keepalives without giving users an ability to tweak any fine-grained parameters. Ordinarily this isn't a problem, particularly for users that have fast-enough connections, and/or are talking to a server that has generous or nonexistent thresholds for killing a connection it hasn't heard from in a while. But it can present a problem when one or both of those assumptions fail. For instance, I can reliably get an in-progress clone to be killed from the remote end when cloning from some forges while using trickle to limit my clone's bandwidth. For those users and others who wish to more finely tune the OS's keepalive behavior, expose configuration and environment variables which allow setting curl's KEEPIDLE, KEEPINTVL, and KEEPCNT options. Note that while KEEPIDLE and KEEPINTVL were added in curl 7.25.0, KEEPCNT was added much more recently in curl 8.9.0. Per f7c094060c (git-curl-compat: remove check for curl 7.25.0, 2024-10-23), both KEEPIDLE and KEEPINTVL are set unconditionally. But since we may be compiled with a curl that isn't as new as 8.9.0, only set KEEPCNT when we have CURLOPT_TCP_KEEPCNT to begin with. Signed-off-by: Taylor Blau Acked-by: Elijah Newren Signed-off-by: Junio C Hamano

git-curl-compat: remove check for curl 7.56.0

2024-10-23T20:16:35Z

libcurl 7.56.0 was released in September 2017, which is over seven years ago, and no major operating system vendor is still providing security support for it. Debian 10, which is out of mainstream security support, has supported a newer version, and Ubuntu 20.04 and RHEL 8, which are still in support, also have a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.53.0

2024-10-23T20:16:35Z

libcurl 7.53.0 was released in February 2017, which is over seven years ago, and no major operating system vendor is still providing security support for it. Debian 10 and Ubuntu 18.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.52.0

2024-10-23T20:16:35Z

libcurl 7.52.0 was released in August 2017, which is over seven years ago, and no major operating system vendor is still providing security support for it. Debian 9 and Ubuntu 18.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.44.0

2024-10-23T20:16:35Z

libcurl 7.44.0 was released in August 2015, which is over nine years ago, and no major operating system vendor is still providing security support for it. Debian 9 and Ubuntu 16.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.43.0

2024-10-23T20:16:35Z

libcurl 7.43.0 was released in June 2015, which is over nine years ago, and no major operating system vendor is still providing security support for it. Debian 9 and Ubuntu 16.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.39.0

2024-10-23T20:16:35Z

libcurl 7.39.0 was released in November 2014, which is almost ten years ago, and no major operating system vendor is still providing security support for it. Debian 9 and Ubuntu 16.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.34.0

2024-10-23T20:16:35Z

libcurl 7.34.0 was released in December 2013, which is well over ten years ago, and no major operating system vendor is still providing security support for it. Debian 8 and Ubuntu 14.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau