e2b: downloads ignore If-Range and can corrupt resumed files

[sweetcornna]

What happened

Dormice advertises byte ranges and returns a Last-Modified validator for signed E2B downloads, but chooses between full and partial responses solely from Range. It never evaluates If-Range.

Reproduction:

1. Write UVWXYZ to a sandbox file and obtain its signed download URL.
2. Request it with Range: bytes=3- and the guaranteed-stale validator If-Range: Thu, 01 Jan 1970 00:00:00 GMT.

Expected: Because the validator does not match the current representation, the server ignores Range and returns HTTP 200 with the full UVWXYZ body.

Actual: Dormice returns HTTP 206 with only XYZ.

Impact: A standards-compliant download manager can append bytes from a replacement file to an older partial copy. For example, appending the returned XYZ to an old abc prefix silently produces corrupt abcXYZ instead of restarting with UVWXYZ.

Relevant code and contract:

• packages/server/src/e2b/envd/files.ts:141-160 parses only the Range header.
• packages/server/src/e2b/envd/files.ts:215-245 chooses 206 whenever that range is a slice and emits Last-Modified, without consulting request.headers['if-range'].
• website/content/docs/e2b-differences.mdx:26-27 advertises range support specifically for interrupted-download resume.
• HTTP range semantics require a recipient to ignore Range when an If-Range validator does not match and send the complete selected representation instead.

dor doctor output

Not applicable — this is signed-download HTTP behavior and does not depend on host readiness.

Environment

• Dormice commit: 4417ae14938273f5d937c476cf7cdc57e22e53a5
• Client: any HTTP range client using If-Range
• Executor: Docker + gVisor (protocol decision is executor-independent)
• Verification: deterministic stale-date request against the signed download handler