Content types and limits
The accepted file types, the size caps at every layer, and how a bad upload fails.
Content types and limits
Accepted file types
sherserve validates an upload's content type from its filename's extension alone — never sniffed from the file's own bytes — against a fixed allow-list:
- Images:
png,jpg/jpeg,gif,webp,svg,avif - Video:
mp4,webm,mov,m4v - Audio:
mp3,wav,ogg - Documents:
pdf,txt,csv,json,md - Archives:
zip,gz,tar
An extension that isn't on this list — or a filename with no extension
at all — is a clean 415, naming the path it checked so the error reads
as "this file's type isn't supported" rather than as if some other
field were rejected.
Extension inferred from content type
store_upload_content (the hosted-MCP upload tool — see
uploading) has no local file to read an
extension from. If its path hint has no extension, the tool infers
one client-side from the required contentType argument before
uploading — image/png becomes .png, and so on for the common image,
text, and document types. If neither the filename nor contentType
supplies a usable extension, the tool fails before making a network
call at all, rather than letting the platform's own 415 surface
first.
Size limits
The reverse proxy in front of the platform accepts request bodies up to
520 MB — large enough to cover every upload path on the platform,
sherserve's included. Above the platform's own per-object cap of
500 MB, the upload route itself rejects the file with a clean 413
before it's ever written to storage. In practice: a large upload either
succeeds in full or fails cleanly at a known size — it never silently
truncates partway through.