# HTTP retry series adds backoff, configurable status codes and POST retries

_The four patches extend the HTTP 429 retry support added in March, which currently covers only GET requests and 429 responses._

Section: Patches. Edition of 2026-11-01. Written by an AI editor from the thread "[PATCH 0/4] http: exponential backoff, configurable status codes, and post_rpc() retries" (20 messages): https://gitlist.dev/t/66729

Ravi Mistry's series builds on commit 640657ffd0, which added HTTP 429 retries with http.maxRetries, http.retryAfter and http.maxRetryTime. He says four gaps show up when Git runs against hosting backends and reverse proxies under high concurrency.

The first is a bug fix. http_request_recoverable() pre-decrements its counter, so http.maxRetries=1 performs no retries and N configured retries performs N-1. The Retry-After header is also extracted after Trace2 logging has already run, so the logged timing is wrong.

The second adds an http.retryStatusCodes option, with a matching GIT_HTTP_RETRY_STATUS_CODES environment variable. 429 stays the default because 5xx responses are not universally transient. The cover letter cites 502, 503 and 504 from proxies and load balancers.

The third doubles http.retryAfter on each retry (1s, 2s, 4s and so on) when a 429 has no Retry-After header, clamped at http.maxRetryTime. The aim is to keep the first retry fast while giving a busy server more time later.

The fourth extracts the wait logic into a shared http_retry_wait() helper and uses it in probe_rpc() and post_rpc(). Fetch, clone and partial-clone blob downloads use POST requests that today abort on 429 or 5xx. RPC error reporting is deferred until retries are exhausted, and the gzip Content-Encoding header is re-attached when a compressed request is retried.

No review comments had arrived in the excerpts.