Customer file upload

You do not already have the file. RFC 9110's POST and PUT are the usual browser methods. The job is finished when your store has a complete object and, if you promised it, a virus scan or a format check has passed.

This is the reverse of client file delivery, and the failure sits on your intake rules. A 25 MB form limit rejects a 2 GB export the customer can see on their desktop. A session timeout at 30 minutes kills a phone upload that needed 40. A filename used as the object key lets a second customer overwrite the first. Intake has to name the max size, the allowed types, the destination key, and what "received" means.

A claims portal asks a customer for a 800 MB dashcam clip. The form allows 2 GB, uses a resumable upload, and writes `claims/4491/<generated-id>.mp4`. The customer's train drops the radio at 500 MB. The client resumes, the complete call runs, and the claim shows the clip at 14:22. A second portal with a 100 MB proxy limit and no resume shows a spinner, then an error, and the adjuster has no video. The customer did their part. The intake did not. An SFTP variant is the same direction with a different door: the customer writes to `inbound/` and a job picks up files that are no longer growing.

Do not mark the upload received on the first byte. Partial objects fail the downstream tool and look like customer error. Pair the upload with a byte-count check before the thank-you page.