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

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

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