File upload

The sender initiates the move. The receiver's system is the destination. In HTTP, that is typically PUT or POST as described in RFC 9110. In FTP, it is STOR.

Direction is the whole distinction from file download. The same file, the same afternoon, is an upload for the person who has it and a download for the person who fetches it later. Product copy that says "upload a download link" is mixing the two legs. The upload ends when the server has the object and acknowledges it. The recipient has not received anything yet.

Uploads fail in the middle more often than the happy path suggests. A browser tab sleeps. A phone radio drops. A proxy cuts a request at a size the application never documented. The server may keep a partial object, reject it, or, with a multipart or resumable API, hold parts until the client sends the rest. Base HTTP does not resume a broken POST. If the client retries the whole request, you can get two copies unless the server treats the upload as idempotent.

A client portal asks for a 600 MB source video before a 18:00 review. The browser POSTs the file at 17:12 on a 20 Mbps up link. The useful upload time is about 600 × 8 / 20 = 240 seconds, four minutes, before overhead. At 17:14 the laptop sleeps and the request dies at 310 MB. The portal shows no file. The reviewer at 18:00 has nothing to open. The producer did not "share" the video. The upload did not complete.

Email attachments are uploads too, with a smaller ceiling. A 25 MB mailbox limit is an upload limit on that path, not a property of the file. Crossing it pushes the sender to object storage and an expiring link. The upload still happens. It happens to a storage API instead of an SMTP server.

Encryption in transit covers the path to the server. It does not decide who can download the object afterward. Access after the upload is a separate setting: private object, password link, or open URL.