[fangpenlin]

Port of the two range-handling follow-ups from cloudflare/serverless-registry#147 onto this fork's main. Core range forwarding is already here (PR #1 + d0d3838); these two edge cases were not.

Suffix ranges (bytes=-<n>)

Range: bytes=-1024 is the RFC 9110 suffix form asking for the last 1024 bytes. The parser required at least one digit before the dash, so this valid form was treated as malformed and silently downgraded to a full 200 response.

BlobRangeRequest is now a union of an offset range and a suffix range. The R2 backend resolves the suffix against the object size, and RegistryHTTPClient forwards it upstream verbatim as bytes=-<n>. Per RFC 9110, a suffix longer than the object is satisfied by the whole object, while a zero-length suffix is unsatisfiable and returns 416.

Upstream 416 reported as 404

When a blob is not cached in R2, the handler falls back to the configured upstream registries. The loop treated every upstream error as a miss and continued, so an upstream 416 was discarded and the request bottomed out at a synthetic 404 BLOB_UNKNOWN.

That told the client the blob does not exist, when it does, and dropped the Content-Range: bytes */<size> header carrying the size the client needs in order to retry. An upstream 416 is now returned directly, matching how a 416 from the primary R2 store is already handled. Other failures still fall through to the next registry.

Testing

New tests, all driven through the worker or the real HTTP client:

• suffix range returns the last bytes as 206, oversized suffix returns the whole object, bytes=-0 returns 416, and bytes=- still serves the full object
• an uncached blob whose upstream answers 416 reaches the client as 416 with its Content-Range intact
• a non-416 upstream failure still falls through to a second registry
• RegistryHTTPClient forwards { suffix: 4 } as Range: bytes=-4 and surfaces the partial content

Verified against main's production code (tests from this branch, source from main): suffix range returns 200 instead of 206, and an upstream 416 is reported as 404. After the port both assertions pass.

pnpm typecheck, pnpm lint and pnpm format:check all pass. The 7 new tests plus the existing blob-range suite pass. The full suite is 71 passed / 2 failed; both failures are the pre-existing background layer caching tests exceeding the default 5s vitest timeout, which reproduce on unmodified main.

This supersedes draft PR #3, which has the same two commits on an older agent branch.