Link revocation

The recipient who saved the link gets a refusal on the next request. A file already downloaded is not pulled back. Revocation covers future fetches, not copies on disk.

How you revoke depends on how the link was built. An application link that checks a row in a database dies when that row is marked dead. The next GET sees the flag and returns 403 or 404. A presigned object-store URL is harder. The signature is valid until the timestamp. AWS documents that the URL works until it expires. Early death means deleting the object, renaming it, or retiring the access key that signed it. Retiring the key kills every URL that key signed, not just the one you regret. Deleting the object kills every link to that key, including ones you still wanted.

At 10:00 a producer sends a 48-hour link to the wrong client. At 10:20 they hit revoke. With an app-gated link, the 10:21 download fails and the access log shows the deny. With a presigned URL and no object delete, the wrong client still fetches the file at 11:00. The revoke button that only hid the link in the sender's UI did nothing to the signature. The working move is delete or overwrite the object, then upload a new key for the right client.

Expiry is not revocation. Expiry fires on a clock if nobody acts. Revocation is someone acting early. One-time links are a cousin: the first successful download burns the URL. A failed or partial download may or may not burn it, and that rule has to be written down or the sender will not know whether the wrong person consumed the single use.

HTTP has no unsend. RFC 9110 does not define a method that reaches into the recipient's client and erases a URL. Caches add a lag. A CDN can keep serving a public object after the origin delete until the cache entry expires or someone purges it. Revocation plans that ignore the cache are not done.