--- changelog: category: Release version: files-sdk@3.0.0 date: '2026-10-09T07:56:36Z' seo: description: >- files-sdk/cache no longer shares entries between instances. Store keys now include the instance prefix, and a custom store requires a namespace naming the… title: files-sdk@3.0.0 type: changelog --- ## Major Changes - 0223b30: `files-sdk/cache` no longer shares entries between instances. Store keys now include the instance `prefix`, and a custom `store` requires a `namespace` naming the bucket it caches (`cache({ store, namespace: "uploads-prod" })`); without one, `cache()` throws `Invalid`. Reusing one `cache()` on an instance with a different adapter or `prefix` also throws `Invalid`, so create one per instance. Before, two tenants sharing a store could read each other's cached bytes, URLs, and metadata. - 0223b30: The `files-sdk/api` gateway now refuses client keys and `list`/`search` prefixes inside the `versioning()` store (`.versions/`) or the `softDelete()` trash (`.trash/`) with a 403, so a client can't hard-delete trashed objects, wipe version history, or forge versions through the core operations. Use the plugin operations instead. Under an authorize `keyPrefix`, a tenant's own folders with those names stay ordinary keys. - 0223b30: The Google Drive adapter (`files-sdk/google-drive`) now refuses `upload({ cacheControl })` with `Unsupported` (`capabilities.cacheControl` is `false`): Drive never serves it, and the value was silently dropped. It also declares `signedUpload.contentType: true`, since the session binds the type, and no longer offers resumable uploads when built from a pre-built `client`, where they always threw. - 0223b30: `signedUploadUrl({ minSize })` without `maxSize` now throws `Unsupported` on `files-sdk/s3`, `files-sdk/s3-fetch`, `files-sdk/r2`, `files-sdk/bun-s3`, and the adapters built on them, instead of returning a presigned PUT that silently accepts empty uploads. On `s3()`, pass `maxSize` too to get a POST policy that enforces both. `minSize: 0` still returns a PUT. - 40a3694: The array (bulk) forms of `upload`, `download`, `head`, and `delete` now resolve to one shape, `BulkResult` = `{ results: T[]; errors?: BulkError[] }`, instead of four differently named arrays. - **Field renames:** read `results` where you read `uploaded`, `downloaded`, `files`, or `deleted`. `exists([…])` keeps its `{ existing, missing, errors? }` split. - **Type changes:** `UploadManyResult`, `DownloadManyResult`, `HeadManyResult`, and `DeleteManyResult` are now aliases of `BulkResult`. `DeleteManyOptions` is an alias of `BulkOptions`, and `DeleteManyError` is removed in favour of `BulkError` (the same `{ key, error }` shape). - **`stopOnError` on a bulk `delete`:** it now always deletes one key at a time and skips the adapter's native batch, because a batch request can't stop partway. So it returns the same result with or without plugins installed, where before the native path and the plugin path could disagree. - **Custom adapters:** an `Adapter.deleteMany` returns `{ results, errors? }`. - **Gateway, client, CLI, and MCP:** the `files-sdk/api` wire, `files-sdk/client`, the `useFiles` bindings, and the CLI and MCP bulk output use the same shape. - 58e15bc: Adapters now declare what they can do as one `capabilities` object, and `files.capabilities` gains the fields the old flags couldn't express. - **Custom adapters:** the separate `supportsRange`, `supportsDelimiter`, `supportsMetadata`, `supportsCacheControl`, `supportsServerSideCopy`, `reportsUploadProgress`, and `signedUrl` fields on `Adapter` are replaced by `capabilities: { rangeRead, delimiter, metadata, cacheControl, serverSideCopy, uploadProgress, signedUrl, signedUpload }`. Every field is optional and defaults to unsupported. `resumable` and `conditional` are still derived from `resumableUpload` and `conditional`. Declare it per instance, so a constructor option that changes what the adapter can do (a `publicBaseUrl`, an access mode, the `fetch` client) is reflected. Rename the old flags: `supportsRange` → `rangeRead`, `supportsDelimiter: true` → `delimiter: "any"` (or `"slash"`), `supportsMetadata` → `metadata`, `supportsCacheControl` → `cacheControl`, `supportsServerSideCopy` → `serverSideCopy`, `reportsUploadProgress` → `uploadProgress`, top-level `signedUrl` → `capabilities.signedUrl`. The old fields are ignored and anything you leave out is off: without `signedUrl.supported`, `url(key, { expiresIn })` throws `Unsupported` before your `url()` runs; without `signedUpload`, the gateway proxies every upload; without `signedUrl.disposition` or `publicUrl`, it proxies downloads. - **`files.capabilities`:** `multipart` is renamed `resumable` (it always described `upload({ control })`). `delimiter` is now `"any" | "slash" | false`, since Vercel Blob, Netlify Blobs, Supabase, Dropbox, Box, OneDrive, and SharePoint only accept `"/"`. `signedUrl` gains `expiry: "exact" | "provider" | "none"`: Box, PocketBase, and Dropbox's 4-hour temporary links are `"provider"`, because the provider sets the lifetime. There's a new `signedUpload: { supported, maxSize, contentType, maxExpiresIn? }` describing `signedUploadUrl()`, and plugins that refuse direct uploads (`encryption`, `compression`, `dedup`, `validation`, `contentType`) turn it off. - **Gateway (`files-sdk/api`):** presigning uploads now follows `signedUpload` instead of the download `signedUrl` flag. An upload is presigned only when the adapter can bind the gateway's `maxUploadSize` and the file's content type; otherwise it goes through the proxy, which enforces both. UploadThing in its default public-read mode now reports `signedUrl.supported: false` (its `url()` is a permanent link) while still presigning uploads, and Vercel Blob in public mode now gets direct presigned uploads instead of proxied ones. - **Checks run before plugins:** an unsupported `range`, `metadata`, `cacheControl`, `control`, or `delimiter` is now refused before any plugin runs, checked against the plugin-narrowed capabilities, so a plugin can no longer do I/O (a version snapshot, a trash move) for a call that's about to be rejected. When a plugin is what turned the option off, the error names it, for example `range downloads are not supported by the "encryption" plugin`. - 7ca626f: `FilesError` gains two codes, `Invalid` and `Unsupported`, split out of `Provider`, which now only means the backend or transport failed. - **`Invalid`:** the call itself is wrong. That covers an empty, null-byte, or `..` key, a malformed range, ETag, or condition, contradictory options, an `expiresIn` past a hard cap, missing or bad constructor config, and a file a `validation()` rule rejects (`ValidationError` keeps its `reason`). - **`Unsupported`:** the call is well-formed but this adapter, in this mode and with these plugins, can't do it. That covers a `range`, `metadata`, `cacheControl`, `delimiter`, or `control` the adapter has no primitive for, `url()` without a `publicBaseUrl` on FTP/SFTP/WebDAV, a `signedUploadUrl()` `maxSize` or `contentType` the provider can't bind, and the fail-closed refusals of `encryption()`, `compression()`, `dedup()`, `validation()`, and `contentType()`. - **`permanent`:** both new codes are always `permanent` and are never retried or failed over. `Provider` is still the only retried code. `versioning()`'s `restoreVersion()` and `softDelete()`'s `restoreTrashed()` now throw `NotFound` when there's nothing to restore. - **Code that branches on `error.code === "Provider"`** to catch bad input or unsupported options must also check `Invalid` / `Unsupported`. - **Gateway (`files-sdk/api`):** an `Invalid` error is answered with a `422` and the wire code `Validation` (it was a `500`), and an `Unsupported` one with a `422` and the new wire code `Unsupported`. `files-sdk/client` and the `useFiles` bindings turn both back into the matching `FilesError` code, and map any wire code they don't know to `Provider`. When presigning an upload, the gateway falls back to its proxy only for an `Unsupported` or `Invalid` refusal; a backend failure or an abort now surfaces instead of being masked as a proxy target. - **CLI:** `files` now exits `5` for a `Provider` failure, so a script can tell "the backend failed, retry" from "the command is wrong". `Invalid`, `Unsupported`, and `ReadOnly` exit `2`, like a usage error. A missing optional `@modelcontextprotocol/sdk` for `files mcp` is reported as `Unsupported`. - 9765e54: `head()`, `list()`, `listAll()`, and `search()` now return a `FileInfo` (`{ key, size, contentType, etag?, lastModified?, metadata? }`), metadata with no body, instead of a `StoredFile`. - **No more hidden downloads:** in v2, head and list results carried `text()` / `arrayBuffer()` / `blob()` / `stream()` accessors that quietly issued a full download when called. Reading bytes is now always an explicit `download()`, which still returns a `StoredFile`. A `StoredFile` is now a `FileInfo` plus the `File`-like `name` / `type` aliases and the body accessors. - **Renamed fields:** on head and list results, read `contentType` where you read `type`, and `key` where you read `name`. - **Upload results:** `UploadResult` is now the same `FileInfo` shape. - **Plugin results:** `versioning()`'s `restoreVersion()` and `softDelete()`'s `restoreTrashed()` resolve to a `FileInfo`. - **Custom adapters:** `Adapter.head()` and `Adapter.list()` return `FileInfo`. `createStoredFile()` takes a `FileInfo` (with `contentType`, not `type`), and the `StoredFileMeta` type is removed. - **Gateway, client, and UI:** the `files-sdk/api` wire, `files-sdk/client`, the `useFiles` bindings, and the shadcn registry components use the same shape: `contentType` instead of `type`. The client's `upload()` result is now a `FileInfo` too, and the registry components' `onSelect` / `file` / `renderPreview` values are `FileInfo`. - **AI tools:** the AI tool results (`getFileMetadata`, `listFiles`, `downloadFile`) also carry `contentType`. - **CLI and MCP:** `head`, `list`, `search`, and `download` output prints `contentType` instead of `type`, and no `name`. - 6682759: Remove the `defaultUrlExpiresIn` option from the filesystem adapter (`files-sdk/fs`). It was accepted for backward compatibility and ignored, because `url()` returns a permanent `file://` or `urlBaseUrl` link that can't expire. Delete it from your `fs({ … })` options. The CLI's global `--default-url-expires-in` flag no longer reaches the fs adapter, which never used it. - 6682759: Require Node.js 22 or later. Node 20 reached end of life in April 2026, and the package's `engines` field now reads `>=22`. Bun and the edge runtimes the gateways target are unaffected. No peer dependency range is narrowed: Nitro 2 / h3 1 stays supported because Nuxt 4 still runs on it. - 21dd625: `url(key, { expiresIn })` now always means "give me a link that expires", instead of sometimes returning a permanent link that silently ignored the request. - **Adapters that can sign:** S3 and the S3-compatible adapters, R2, GCS, Firebase, Azure, Supabase, and Bun's S3 now return a signed URL for an explicit `expiresIn` even when a `publicBaseUrl` is configured, the same way `responseContentDisposition` already did. A plain `url(key)` still returns the permanent CDN link. - **Adapters that only have permanent links:** Vercel Blob in public mode, UploadThing `public-read`, Convex, Appwrite, the filesystem, and OneDrive / Google Drive in public-link mode now throw an `Unsupported` `FilesError` for an explicit `expiresIn`, before the adapter is called. Before, they returned the permanent link. Leave `expiresIn` out to get that link. - **Provider-set lifetimes:** Box, PocketBase, and Dropbox's tokenized links keep a lifetime set by the provider (`signedUrl.expiry: "provider"`). Box and Dropbox in their public-link modes (`publicBaseUrl` / `publicByDefault`) now return that tokenized link for an explicit `expiresIn`, instead of the permanent share link. - **Two new capabilities:** - `files.capabilities.publicUrl` reports whether a plain `url(key)` returns a permanent link on this instance. - `files.capabilities.signedUrl.disposition` reports whether a `responseContentDisposition` is bound into the signed URL. - Custom adapters declare both in their `capabilities` (they default to `false`). - **Gateway downloads (`files-sdk/api`):** a download now redirects to a signed URL only when the adapter can also bind the forced `Content-Disposition`, and otherwise streams through the proxy. With no forced disposition and no `authorize` lifetime cap, an adapter with a permanent public link is redirected to it. - **Gateway `url` operation:** it signs whenever the adapter can. On an adapter that can't sign, a client-requested `expiresIn` or an `authorize` `maxExpiresIn` is answered with a `422` instead of a permanent link. - **`signedUrlPolicy()`:** it no longer pins a missing `expiresIn` on an instance that can't sign, which would now throw. ## Minor Changes - d70c0d2: The Dropbox adapter (`files-sdk/dropbox`) now forwards the abort signal to every Dropbox API request. Cancelling a call, or hitting its `timeout`, aborts the in-flight upload, download, listing, copy, delete, metadata, link, or resumable-chunk request instead of letting it run to completion in the background. This uses the SDK's per-request transport options (`dropbox` 10.42 and later); older versions ignore them and behave as before. Buffered uploads over Dropbox's 150 MB single-call limit now use a concurrent upload session when `dropbox` 10.47 or later is installed: `multipart.concurrency` chunks (default 4, matching the S3 adapter) upload in parallel through the SDK's new `uploadFile` helper, with retries left to the `Files` wrapper's `retries` and `onRetry`. Pass `multipart: { concurrency: 1 }` to keep the sequential session. Stream bodies and resumable uploads stay sequential, and older `dropbox` versions keep the sequential session for every upload. The peer range is unchanged. - 44b0a35: `files-sdk/events` now reads notifications from Backblaze B2, Tigris, Supabase (a Database Webhook on `storage.objects`), Cloudinary, Appwrite and Box, from S3 delivered by SNS over HTTPS, and from Storj, which publishes S3-format events to Google Pub/Sub. The `s3` format unwraps a Pub/Sub message, whether pushed, pulled, or handed over by the Node client library. The matching adapters pick their format automatically. `webhook()` verifies each provider's own signature with `verify: { secret }`: - B2: HMAC-SHA256. - Cloudinary: SHA-1 or SHA-256, checked for freshness. - Appwrite: HMAC-SHA1 over the configured URL, so pass `url`. - Box: primary or secondary key, checked for freshness. `verify: { sns }` checks SNS message signatures against the certificate at `SigningCertURL`. That URL must be an HTTPS SNS host on the default port, with no credentials, query or fragment. `topicArn` (one ARN or several) is required. SNS signs messages for any topic, including one an attacker owns, so the topic is checked on every message, subscription confirmations included. The signed `Timestamp` must be no older than `maxAge` (default one hour). Both checks run before any certificate is fetched, and only a few signing keys are cached. With `confirm: true` it also confirms new subscriptions to the pinned topic. B2 hide markers, which a delete through `files-sdk/backblaze-b2` produces, count as deletes. Box keys are rebuilt relative to the adapter's `rootFolderId`. Box reports a trashed file at its Trash location, so `FILE.TRASHED` gets a key only for a file that sat directly in the root folder. Cloudinary events for another resource type are dropped. - 44b0a35: Add `files-sdk/events`, a plugin that turns each provider's bucket notifications into one event shape. Install `events()` with `createFiles` and `files.events` gains: - `on(type, glob?, handler)` for `created` / `deleted` events, matched against the caller-facing key. - `dispatch(delivery)` and `parse(delivery)` for queue consumers. They accept an SQS or Lambda event, an R2 Queue message, a Pub/Sub message, an EventBridge event, or an array of them. - `webhook({ verify })`, an endpoint with the gateway's `{ handle }` shape for providers that push over HTTP. It answers the Event Grid and CloudEvents handshakes and authenticates every delivery: with a shared token, or with a Google-signed OIDC token for Pub/Sub push. A Google token must match both the `audience` and the push subscription's service account (`email`), and both are required, since anyone can mint a Google-signed token for any audience. A failed certificate or key fetch answers `502` and a throwing handler `500`, so the provider redelivers. A handler's error message never reaches the response; it goes to `onError`. Other unexpected failures go to the webhook's own `onError`. It reads S3 (SQS, Lambda, SNS → SQS, SNS → Lambda, EventBridge), MinIO and RustFS webhooks, Wasabi (through SNS), R2 Queues, GCS Pub/Sub and Eventarc, and Azure Event Grid in either schema. Adapters declare the format their provider sends as a new `capabilities.events`, which `files.capabilities.events` reports: `s3()` and `s3Fetch()` declare `"s3"` only against AWS, since an S3-compatible endpoint may not send S3's shape, while `minio`, `rustfs`, `wasabi`, `r2`, `gcs`, `firebase-storage` and `azure` declare theirs. Parsing on an adapter with no format throws `Unsupported` instead of guessing, and a malformed delivery throws `Invalid`. Delivery is at least once and out of order on every provider, so each event carries an `id` to dedupe on, and an optional `dedupe` store drops repeats. The id is the provider's event id, or is built from the key and the provider's sequencer, version, timestamp or ETag. A record with none of those gets a hash of itself, never the clock, so a redelivery always keeps its id. Events outside the instance `prefix` are dropped. So are events for another bucket: the `bucket` filter defaults to the adapter's own bucket when it exposes one, and `bucket: false` turns it off. Gateway uploads reach the same handlers, and `events({ sdk: true })` adds writes made through the instance. With `sdk: true`, `events()` must come before any plugin that maps storage keys or sizes; otherwise the instance throws `Invalid` when it's built. On an instance that reads a format, `on()` throws when a plugin refuses provider events, as `webhook()` does. The memory adapter emits events natively, with `settled()` for tests. Plugins gain an optional `event` hook for mapping provider events. `dedup()`, `encryption()`, `compression()`, `versioning()`, `softDelete()` and `tiering()` use it, so their internal keys and stored sizes don't leak into events. The `files` CLI gains `files events parse [file] --format ` for debugging a payload. - 10674b2: Add `files.abortUpload(key, token)` to discard a persisted resumable upload from its session token. `UploadControl.abort()` discards the provider-side session only while the control is driving an upload: a control rebuilt with `UploadControl.from(token)` in a new process has no adapter to call, so its `abort()` marked it aborted and left the session behind (an S3 multipart upload kept its billed parts). `abortUpload()` takes the same logical key and the `control.toJSON()` token and does what `abort()` does mid-upload: S3 and the S3-compatible adapters issue `AbortMultipartUpload`, GCS, Firebase Storage, Google Drive, OneDrive, SharePoint, and Supabase cancel the session, `fs`, FTP, and SFTP remove the staged partial, and Appwrite deletes the partial file. Adapters whose provider has no cancel primitive (Azure, Dropbox, Cloudinary, Vercel Blob) resolve and let the session expire. A token for another key, bucket, or provider throws `Invalid` before anything is discarded, a session that's already gone resolves while a cancel the provider refuses rejects, and the call throws `ReadOnly` on a read-only instance and `Unsupported` on an adapter without resumable uploads. The Appwrite adapter (`files-sdk/appwrite`) also now checks that a file is still partially uploaded before a discard deletes it, so aborting from a stale token, or after a resumed upload failed against a file that had since completed, no longer deletes the finished file. The resumable-upload docs now say plainly that the browser client (`files-sdk/client`, `useFiles`) can't pause or resume across a reload in 3.x. - 44b0a35: Add an upload lifecycle hook to the gateway (`files-sdk/api`). `createFilesRouter({ onUploadComplete })` runs on the server once per verified upload: in `complete` for keyless uploads, after the gateway `head`s the landed object and checks `maxUploadSize`, and after a keyed `upload(key, body)` stores its body. Record the upload there instead of building a second endpoint and trusting the client to call it. The hook receives the caller-facing `file` metadata, its `storageKey`, the request, a stable `uploadId` and how the bytes arrived (`via`). `authorize` can now return `context` (the signed-in user, say), which reaches the hook typed. Whatever the hook returns comes back to the browser as the upload result's `data`, in `createFilesClient`, the React, Vue and Svelte `useFiles` bindings (results and `uploads` entries), and the registry `Dropzone` / `MultipartUploader` `onUploaded` callbacks. Type it with `useFiles>()`. Throwing from the hook rejects the upload: the gateway deletes the object and the client's `upload()` rejects with the error (`UploadRejectedError` gives a 422 with your message). A removal that fails is reported alongside the rejection. Set `onRejected: "keep"` to keep rejected objects, including ones the complete-time `maxUploadSize` check refuses. Upload tokens are stateless, so a replayed `complete` fires the hook again with the same `uploadId`; pass a `completions` store to make completions single-use. - d70c0d2: Add a `region` option to the Netlify Blobs adapter (`files-sdk/netlify-blobs`). Site-wide stores don't read a region from the environment, so until now they always used the Netlify API's default region rather than the site's Functions region. Pass `region: "eu-central-1"` (or any region `@netlify/blobs` supports) to keep a store's data next to the functions that read it. Deploy-scoped stores keep defaulting to the deploy's region, and changing `region` later doesn't move data a store already holds. No peer range change: every supported `@netlify/blobs` version forwards the option. - 90fc706: Support Nitro 3 / h3 2 in the Nitro gateway binding (`files-sdk/nitro`), alongside Nitro 2 / h3 1. h3 2 hands every runtime a Web `Request` on `event.req`, and the binding now passes it to the gateway as-is. Before, it read `event.node`, which h3 2 only provides on Node, so the route failed with a 500 on Bun, Deno, and edge presets. On h3 1 nothing changes: the Node request is still marshalled, and in-process requests (`localFetch`, SSR `$fetch`) still read their body from the event. The binding no longer imports anything from `h3`, including types, so it typechecks in Nitro 3 apps that only reach h3 through `nitro/h3`. `createRouteHandler`'s parameter is the new structural `NitroEvent` type, which both majors' `H3Event` satisfy, and the `h3` peer range widens to `^1.0.0 || ^2.0.0`. - 6682759: An empty `prefix` (`""`) or an all-slash one (`"/"`) passed to `new Files({ prefix })` now means no prefix, the same as leaving the option out, instead of throwing "prefix must be a non-empty string". This keeps `prefix: process.env.FILES_PREFIX ?? ""` working when the variable is unset. ## Patch Changes - 5cdab4f: Fix `createFileTools()` from `files-sdk/ai-sdk` not typechecking with AI SDK 7. `FileTools` was declared as an `interface`, which has no implicit index signature, so it wasn't assignable to `ai`'s `ToolSet` and `generateText({ tools: createFileTools({ files }) })`, `streamText`, and `new ToolLoopAgent({ tools })` failed to compile with "Index signature for type 'string' is missing". `FileTools` is now a type alias with the same members. `AgentsFileTools` from `files-sdk/openai` gets the same change, so it's assignable to a `Record`. The Vercel AI SDK docs also now spell out that an AI SDK 7 `toolApproval` function overrides every tool's `needsApproval`, and that returning `undefined` from it runs a write without approval. - 647b04a: The published build no longer imports `node:module` from the root `files-sdk` entry, `files-sdk/r2`, or the other adapter and plugin entries. Bun 1.4.0's bundler emitted an unused `createRequire` shim chunk and imported it from almost every entry, so a Cloudflare Worker without the `nodejs_compat` flag failed to bundle Files SDK with `Could not resolve "node:module"`. The package is now built with Bun 1.4.2, which doesn't emit the shim, and a build-output test bundles the Worker-facing subpaths the way Wrangler does to keep it that way. - d70c0d2: Fix error classification in the Bunny Storage adapter (`files-sdk/bunny-storage`) on `@bunny.net/storage-sdk` 0.3.2, which started putting the key into its 400 error message. A rejected request for a key containing words like "not found", "forbidden", or "conflict" was misread as `NotFound`, `Unauthorized`, or `Conflict`; the SDK's own message templates are now matched exactly first, so a 400 stays a `Provider` error whatever the key says. - de04cc9: Security: the `files-sdk/api` gateway's `complete` step now checks that an upload token was issued for the caller. It verified the token's signature but never compared its key against the calling request's authorized `keyPrefix`, so one tenant could complete another tenant's token and read back that upload's full storage key and metadata. A token whose key lies outside the caller's prefix now gets an `Unauthorized` entry ("upload token was not issued for this caller") that echoes only the key the caller sent. The proxy upload `PUT` is unchanged: like a presigned URL, its token alone authorizes writing the one key `presign` minted until it expires, and the authorization docs now say so. - de04cc9: The `files-sdk/api` gateway no longer breaks on adapters that can't set `responseContentDisposition` on their URLs (Vercel Blob, Box, Dropbox, PocketBase, UploadThing, Cloudinary, the local `fs` adapter, and the others whose `url()` refuses the option). Before, the default `download` returned a 500 on private Vercel Blob and the other signing adapters among them, and the `url` operation returned a 500 on all of them. Now `downloadMode: "auto"` proxies such a download so `Content-Disposition: attachment` still applies (`"redirect"` still surfaces the refusal), and when `authorize` returns `{ disposition: "inline" }` the gateway mints the URL without a disposition for both `url` and the download redirect. Without that inline policy, the `url` operation still fails (a `422` `Unsupported`), because the gateway can't guarantee `attachment`, but the error now explains how to proceed: allow inline from `authorize`, or use `download`. The adapters' refusal keeps its message and is now an `Unsupported` error, so it is never retried or failed over. - de04cc9: Proxied downloads from the `files-sdk/api` gateway play media and send proper validators. With the default `onUnsupportedRange: "reject"`, a `Range: bytes=0-` request to an adapter that can't serve ranges got a `416`, which broke every `