[fangpenlin]

Follow-up to the range forwarding work in cloudflare/serverless-registry#147, fixing two range edge cases found while reviewing it.

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.

R2 supports suffixes natively (R2Range accepts { suffix }), but resolving against the size we already have from head() keeps the Content-Range construction in one place alongside the existing offset path.

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. A resuming client would abort the pull instead of restarting at a valid offset, which is the failure mode #64 describes.

An upstream 416 is now returned directly, matching how a 416 from the primary R2 store is already handled. Blobs are content addressed, so every registry holding a digest holds the same bytes and would answer the same way. Other failures still fall through to the next registry, which is covered by a test.

Testing

Six 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 the 416 test fails without the fix (expected 404 to deeply equal 416) so it is not vacuous.

pnpm typecheck, pnpm lint and pnpm format:check all pass. The full suite is 71 passed / 2 failed; both failures are the background layer caching tests exceeding the default 5s vitest timeout, which reproduce identically on unmodified main and are unrelated to this change.

range_tests.log

Note for a separate change

RegistryHTTPClient.getLayer has a pre-existing quirk in its redirect retry: when the retried request fails it returns the first response rather than the retry's, so a 416 behind a presigned-URL redirect would still be lost. Left alone here to keep this change focused.

_{To show artifacts inline, enable in settings.}