One-time download link

The second request fails even if the clock has not run out. It is an application counter on top of a link, not an HTTP feature and not a property of a presigned URL. S3 presigned URLs do not count uses. They work until they expire, however many GETs arrive.

The hard part is defining "one download." A browser may send a HEAD, then a GET, then Range requests for the same file. RFC 9110 allows a client to fetch the body in pieces. If the server burns the link on the first GET, a resume fails and the recipient holds a partial file with no way back. If the server burns it only after the byte count matches Content-Length, a client that stops at 90 percent leaves the link live for someone else. The rule has to pick one of those.

A counsel sends a 30 MB agreement through a one-time link at 15:00, expiry 19:00. The client's browser prefetches on hover. A naive server counts that prefetch as the use and the real click at 15:02 returns 410. A server that ignores HEAD and prefetch, and burns the link only after 30 MB have been sent to one token, survives the hover. A second office that received the forwarded mail at 15:10 gets nothing. That is the control working. A preview pane that downloaded the whole PDF at hover is indistinguishable from the recipient, and the real user is locked out. One-time links and aggressive prefetch fight each other.

One-time is not expiry and not revocation. Expiry is a clock. Revocation is a person. One-time is a counter. You can combine them: the link dies at the first full download or at 19:00, whichever comes first. Download tracking is the log of those attempts. The counter is the gate. The log is the record. A team that only logs, and never increments a deny flag, has tracking without a one-time link.