1fe721e651a7c58cf7fce84d1f798499fe1942c6
The Hub answers a resolve request with a redirect: 307 to its own resolve-cache for an ordinary file, 302 to a CDN for an LFS-backed one. X-Repo-Commit, X-Linked-Etag and X-Linked-Size ride on that redirect response; the CDN it points at carries none of them and sets an ETag of its own. reqwest was following the redirect itself, so head_of() only ever saw the final hop. Every recorded etag was the CDN's, X-Linked-Etag and X-Linked-Size were lost, and no file was ever recognised as LFS -- which also meant expected_sha256() never fired, so nothing was verified against upstream's oid and every transfer took the staging path instead of writing straight to its content-addressed key. Follow redirects by hand instead, absorbing replayable metadata only while still on the Hub's origin and taking the content length from whichever hop actually serves the bytes. The operator's upstream token is dropped when a redirect crosses origins, since a presigned CDN URL needs no authorization of ours and forwarding one leaks a credential. Also derives the lfs flag from X-Linked-Size rather than the presence of X-Linked-Etag: the Hub sends a linked etag for every file (a git blob SHA-1 for ordinary ones), so the etag alone marked everything as LFS. Found by running the conformance suite against the MinIO on caveman. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XZG2i4AmfSqE97EJGBVb64
Languages
Rust
81.3%
TypeScript
5.9%
Python
5.6%
Shell
5.4%
CSS
1.6%
Other
0.1%