Expiring link

The file can remain in storage. The URL is what dies. Object stores implement this as a presigned or signed URL: the service stamps the request with a credential and an expiry, and rejects the same URL after that instant.

The link is not the file. Sending the URL is not the transfer. The recipient still has to download, and that download has to finish before the clock runs out. A 6 hour link and a 12 hour download on a slow link is a failed handoff even though the mail went out on time.

A producer uploads a 3 GB cut to a bucket at 14:00 and generates a presigned GET that expires at 18:00. The client opens it at 17:40. The download needs about 20 minutes on their link. At 18:00 the store returns 403 on the next range request. The client holds 2.1 GB of a 3 GB file and cannot resume on that URL. A new link, issued at 18:05 with a fresh expiry, lets them resume only if the client asks for the remaining range and the server still has the object. The first link did its job by refusing the late request.

Expiry is easy to confuse with revocation. An expiring link dies on schedule even if nobody acts. Link revocation kills it early, which signed URLs often cannot do: the signature is valid until the timestamp, unless you also delete the object or rotate the key that signed it. A password-protected link adds a secret the URL does not contain. A public link has neither a clock nor a password. Permanent links are just URLs with no expiry field. They stay valid until someone removes the object or the permission behind them.

Clock skew bites this control. If the signing machine is 10 minutes fast, a "one hour" link can already be dead for the recipient. Operators who set a 5 minute expiry for an upload form see random failures when the user's upload starts late. Match the window to the expected transfer time, not to a security slogan.