Replit Agent prompt to build a file upload endpoint
Upload endpoints get breached through the boring parts: trusted mime headers, original filenames, orphaned objects. This prompt has Replit Agent route files into Object Storage with magic-byte checks, generated storage keys, and a cleanup path for failed inserts, then verify all of it with curl. You end up with an endpoint fit for real traffic.
Last updated
Build a file upload endpoint in this Repl backed by Object Storage, with the built-in Postgres database holding metadata. No files written to the repl filesystem, uploads pass straight through to the bucket. Endpoint: POST /api/files accepting multipart form data. Enforce a size cap and an allowlist of content types, images and PDF to start, detected from the file's magic bytes, not the client-supplied mime header or the extension. Reject early rather than buffering the whole body, an oversized upload should fail fast with 413. Metadata: a files table with id, storage key, original name, byte size, detected content type, uploader when the app has auth, and created_at. The storage key is a generated id plus extension, never the original filename, which is kept only as display metadata. Download: GET /api/files/:id streams from Object Storage with the correct content type and a content-disposition header built from the sanitized original name. An unknown id returns a JSON 404 matching the API's existing error shape. Failure handling: if the storage write succeeds but the database insert fails, delete the orphaned object before returning 500, and leave a code comment stating that cleanup so a refactor does not drop it. Verify from the workspace shell with curl and paste the outputs: a valid image upload returning its id, a renamed executable posing as a .png rejected with 415, an oversize file rejected with 413, a download round trip proven byte-identical with a checksum comparison, and the 404. Then list the changed files and where the size cap constant lives so I can tune it.
Same task in other tools
Questions about this prompt
Why check magic bytes instead of the mime header?
The header and the extension are both controlled by the sender, so a renamed executable sails through either check. Reading the file signature server-side closes that, and the curl test with a fake .png proves the check is live.
I need video uploads too, what do I change?
Add the video signatures to the allowlist and raise the size cap constant the prompt asks the agent to point out. For very large files, ask for an upload flow that streams to Object Storage without holding the body in memory.
Downloads come back corrupted or with mangled names, where is the bug?
Corruption points at the streaming path, and the checksum comparison in the verify list catches it. Mangled names mean the content-disposition header is unsanitized or dropped, keep the display name cleaned but leave the extension intact.