[cdn] fix some range issues where delivered images might be corrupt

apps/cdn/src/cdn.app.ts

@@ -2,7 +2,13 @@ import { Hono } from 'hono'
 import { describeRoute, openAPIRouteHandler } from 'hono-openapi'
 import { useWorkersLogger } from 'workers-tagged-logger'
 
-import { withCleanSpec, withNotFound, withOnError } from '@repo/hono-helpers'
+import {
+	withCleanSpec,
+	withDefaultCors,
+	withNotFound,
+	withOnError,
+	writeContentRange,
+} from '@repo/hono-helpers'
 
 import loadingScreenTipData from '../static/loading-screen-tip-data.json'
 import {
@@ -23,38 +29,41 @@ import type { App, Env } from './context'
  * streamed out of the shared `recflare-cdn` R2 bucket, keyed by prefix.
  */
 
-/** Parse a single-range `Range: bytes=start-end` header into an R2 range. */
-function parseRange(header: string | undefined): R2Range | undefined {
-	if (!header) return undefined
-	const m = /^bytes=(\d*)-(\d*)$/.exec(header.trim())
-	if (!m) return undefined
-	const start = m[1]
-	const end = m[2]
-	if (start === '' && end !== '') return { suffix: Number(end) } // last N bytes
-	if (start !== '') {
-		return end !== ''
-			? { offset: Number(start), length: Number(end) - Number(start) + 1 }
-			: { offset: Number(start) }
-	}
-	return undefined
-}
-
 /**
  * Stream a binary asset from the CDN R2 bucket as application/octet-stream,
  * honoring Range requests. 404s when the file is missing.
  * Supports conditional GET and byte-range requests (206) — large-file
  * downloaders fetch in ranges, and a 200 where a 206 is expected corrupts the
  * reassembled file (e.g. EAC "Signatures don't match").
+ *
+ * This is why `cache.enabled` is false in wrangler.jsonc: Workers Caching strips `Range`
+ * before the worker is invoked and slices the 206 out of its own cache, which silently
+ * degrades to a whole-object 200 whenever the response is not cacheable. The range
+ * answer has to be ours to guarantee.
  */
 async function serveAsset(c: Context<App>, key: string) {
 	if (key.includes('..')) return c.body(null, 400)
 
 	const ifNoneMatch = c.req.header('if-none-match')?.replace(/"/g, '')
-	const range = parseRange(c.req.header('range'))
-	const object = await (c.env as Env).CDN_ASSETS.get(key, {
-		...(ifNoneMatch ? { onlyIf: { etagDoesNotMatch: ifNoneMatch } } : {}),
-		...(range ? { range } : {}),
-	})
+	// R2 parses the `Range` header itself when handed the request headers, so there is no
+	// grammar to reimplement here. It resolves every form (`bytes=a-b`, `bytes=a-`,
+	// `bytes=-n`) to a concrete offset/length, and anything it cannot parse or satisfy to
+	// the whole object — see the 206 branch, which is what turns that back into a 200.
+	// With no `Range` header present this is an ordinary whole-object read.
+	let object
+	try {
+		object = await (c.env as Env).CDN_ASSETS.get(key, {
+			...(ifNoneMatch ? { onlyIf: { etagDoesNotMatch: ifNoneMatch } } : {}),
+			range: c.req.raw.headers,
+		})
+	} catch (e) {
+		// Defensive: R2 documents InvalidRange (10039) for a range it can't satisfy, which
+		// is a 416 rather than the 500 the error handler would otherwise turn it into.
+		// Locally it never fires — workerd resolves an unsatisfiable range to the whole
+		// object instead of throwing — so this covers the service behaving as documented.
+		if (e instanceof Error && e.message.includes('(10039)')) return c.body(null, 416)
+		throw e
+	}
 	if (!object) return c.notFound()
 
 	const headers = new Headers()
@@ -67,20 +76,12 @@ async function serveAsset(c: Context<App>, key: string) {
 	// Precondition matched (If-None-Match) → R2 returns no body.
 	if (!('body' in object)) return new Response(null, { status: 304, headers })
 
-	// Range honored → 206 Partial Content with Content-Range.
-	if (object.range && c.req.header('range')) {
-		// R2 hands back the RESOLVED range, and the object it returns carries all three
-		// keys with the inapplicable ones set to undefined — so `'suffix' in r` is true
-		// even for an offset/length range and cannot discriminate between the two forms.
-		// (It read as a suffix range every time, making offset/length NaN and the
-		// Content-Range header garbage.) Read the values, not the keys. A `bytes=-N`
-		// request already comes back resolved to a concrete offset/length; the suffix
-		// fallback below is only there in case that ever stops being true.
-		const r = object.range as { offset?: number; length?: number; suffix?: number }
-		const length = r.length ?? r.suffix ?? object.size - (r.offset ?? 0)
-		const offset = r.offset ?? object.size - length
-		headers.set('content-length', String(length))
-		headers.set('content-range', `bytes ${offset}-${offset + length - 1}/${object.size}`)
+	// A `bytes=` request is ALWAYS answered 206 with a Content-Range naming the bytes
+	// actually enclosed — never a bare 200 carrying the whole object. That is the one
+	// answer a chunked downloader cannot survive: it asked for a slice, so it writes
+	// whatever comes back at that offset, and a whole-object body silently corrupts the
+	// reassembled file (EAC "Signatures don't match"). See writeContentRange().
+	if (writeContentRange(headers, c.req.raw.headers, object)) {
 		return new Response(object.body, { status: 206, headers })
 	}
 
@@ -98,6 +99,15 @@ const app = new Hono<App>()
 			})(c, next)
 	)
 
+	// The website lets a room's owner download their own scene blobs (see the room page
+	// in `www`), which means a browser reading these bytes from another origin — without
+	// these headers it can fetch them but not touch the result. `origin: '*'` gives away
+	// nothing: every route here is already unauthenticated and public to anyone holding
+	// the key, and nothing on this worker reads a cookie or a token, so there is no
+	// ambient credential for `*` to expose. The keys are unguessable UUIDs, and that is
+	// unchanged by who may read a response they already had to name exactly.
+	.use('*', withDefaultCors())
+
 	.onError(withOnError())
 	.notFound(withNotFound())
 
@@ -247,7 +257,9 @@ app.get(
 						'byte ranges (`Range` → 206). The ranges matter: large-file downloaders fetch in',
 						'chunks, and answering 200 where a 206 is expected corrupts the reassembled file —',
 						'which surfaces as an anti-cheat “Signatures don’t match” failure, not a download',
-						'error.',
+						'error. So a `bytes=` request is never answered with a whole-object 200: the 206',
+						'always carries a `Content-Range` stating which bytes the body holds, even where',
+						'that turns out to be all of them.',
 					].join('\n'),
 				},
 				servers: [{ url: 'https://cdn.recflare.net', description: 'Production' }],