On a 206 those two headers answer different questions: Content-Length is
the length of the range, so a resume at 162 MB reports 72 MB and a bar
drawn from it fills at a third of the model. The arithmetic that was here
(`have + length`) happened to be right, but only because the range always
starts exactly at what is on disk -- it was correct by coincidence of two
things agreeing rather than by asking for the number wanted. Content-Range
carries the whole size as its last field and does not care where the range
began.
Confirmed against HuggingFace: `content-range: bytes
162000000-234074815/234074816` beside `content-length: 72074816`, and a
resumed download now reports 234.1 MB rather than 72.
Two other things checked rather than assumed, both fine as they stood.
Downloads are already single-flight per file -- the check and the insert
happen under one lock, keyed by the model, so a second client asking for
the same file joins the running download instead of starting a second
writer onto the same partial. And HuggingFace's ETag is stable across
requests, with no weak prefix or per-edge variation, so the identity check
will not discard good partials and refetch gigabytes for nothing.
One hypothesis worth recording as false: HF's ETag is not the content
sha256 for these files (`db6593d0…` against a published `55e0d0b8…`), so
the published-hash check cannot collapse into the identity check. Both
earn their place.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw
irisandClaude Opus 5
e50d1a2bbf