File request

The requester creates the slot. The other party is the one who has the bytes. In HTTP that slot accepts POST or PUT, as RFC 9110 defines those methods. The requester's own disk never has to hold the file first.

Direction is the distinction from a share link. A share link is a download. A file request is an upload into a folder or a ticket the requester controls. The requester can be offline when the file arrives. The slot has the same knobs as any upload link: expiry, a password, a size cap, an allowed type, and a count of how many files it will take.

An agency needs a 6 GB shoot from a freelancer by Friday. Email will reject it. The producer creates a request link, expiry Sunday 18:00, cap 20 GB, one folder. The freelancer opens it Thursday, and a resumable client finishes after a cafe Wi-Fi drop. The agency's bucket shows the object at 19:40. No one at the agency uploaded anything. If the freelancer instead receives a download link, they have nowhere to put the shoot. Teams mix the two up in the subject line: "link to send files" can mean either direction. The test is which side starts with the bytes.

A request link is a write permission, which is why it needs a tighter scope than a read link. An open request with no cap becomes a dropbox for strangers. An open request that accepts any path can overwrite a previous delivery if the key is the filename. Pin the destination key, or accept the upload under a generated name, and keep the requester's existing objects out of that prefix. Customer file upload is this pattern when the other party is a customer. The mechanism is the same.