Use case
Deliver heavy files
Up to 2 GB by default, sent by the browser straight to your bucket, in parts, resumed if the connection drops.
[
{
"AllowedOrigins": ["https://drop.example.com"],
"AllowedMethods": ["PUT"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["ETag"],
"MaxAgeSeconds": 3600
}
]The situation
What is actually going on.
The problem
A video edit, a high-resolution export, an archive of sources: too heavy for email, and hosted transfer services keep a copy on their side.
What colis does about it
Above DROP_MAX_SIZE_MB, the delivery page stops sending anything through the function. The browser cuts the file into 8 MiB parts and sends them to the bucket itself, over presigned URLs, four at a time; the server only signs and assembles. If the tab closes or the connection drops, drop the same file again: the page offers to resume and sends only what is missing.
Worth watching
The things that are easy to get wrong.
A CORS rule on the bucket
The parts go from the browser to the bucket, so it has to allow PUT from your page and expose ETag. Without it, small files keep working and large ones fail with a message that says why.
Abandoned uploads cost
Add AbortIncompleteMultipartUpload after one day to the lifecycle rule on the prefix.
The lifetime starts with the upload
The expiry is written when the upload opens, so a slow upload spends some of the lifetime the sender chose.
Related
Other ways to deliver.
Send it. They sign off. You know.
Your storage, a delivery page under your name, a webhook at every step. Nothing hosted by someone else.