Re: [PATCH v6 3/6] http: accept HTTP 416 for complete partial packs

From: Jeff King <peff@peff.net>
Date: Aug 1, 2026, 13:58 UTC
Message-ID: <20260801135844.GB2041176@coredump.intra.peff.net>
In-Reply-To: <677e5399eb8ce260f6aa98d91b5b2634ff95e46c.1785111375.git.tnyman@openai.com>

On Sun, Jul 26, 2026 at 05:28:40PM -0700, Ted Nyman wrote:

Show 11 quoted lines

> A resumed pack request may already have all bytes of the remote pack.
> A server can respond to the resulting Range request with HTTP 416
> instead of returning an empty response.
> 
> Accept that response in each pack-download caller and let index-pack
> validate the completed staging file. This can happen without concurrent
> downloads when a previous attempt completed the transfer but failed
> before indexing it.
> 
> Add a regression test that seeds a complete partial pack and checks that
> http-fetch indexes it after the server returns HTTP 416.

Again, thanks for splitting this out and demonstrating the non-concurrent case. It all looks good to me.

I do wonder what will happen when we get a 416 and we _don't_ have a complete pack. E.g., imagine the file size on the server changed (it shouldn't if they are using the hash of the pack contents as the name, but that's not strictly required).

Previously we'd barf on the curl error. Now we'll guess that we got the full file, even though we have a partial download. Presumably we'd then just barf at the index-pack level. I guess this is not really any different than other resumption problems. If the file changed on the server, we could easily download half of one version and half of another. Ultimately we don't trust any of it until index-pack processes the whole thing.

So this seems like a good direction to me.

-Peff