File download

The recipient initiates the move. In HTTP the method is GET. In FTP it is RETR. The download is finished when the client has a complete local file, not when the server accepted the request.

A download can be partial on purpose. RFC 9110 defines Range requests so a client can ask for a byte span. Installers and video players use that to resume. A progress indicator at 100 percent is not proof. Compare the local byte count to Content-Length, or hash the file if the publisher posted a checksum. A proxy can also gzip a response and confuse a naive size check unless the client compares the decoded body.

A partner publishes a 2.0 GB export at 09:00 with an expiring link. The recipient starts the download on a 50 Mbps down link. Ideal time is 2 × 8 / 0.05 = 320 seconds, a little over five minutes, if the path sustains that rate. At 1.4 GB the office link blips. A client that supports Range resumes at byte 1,509,949,440. A client that does not starts over, and the first partial file sits in the downloads folder with the same name. The operator who opens the partial file sees a corrupt archive and files a false bug against the publisher.

Download is not the same control as file upload. Revoking a link stops future downloads. It does not pull back a file already saved on the recipient's disk. Content delivery network nodes change where the bytes come from, not who is allowed to ask. A cache hit can be fast and still be the wrong object if the publisher replaced the file and the cache kept the old one.

People say "download limit" for three different caps: how many times a link works, how many bytes a plan allows in a month, and how fast the server will send. Those are a count, a quota, and a throttle. They are not the download itself.