Bucket CORS for direct browser uploads, ahead of the rest of media Feature Request open
Summary. A browser cannot PUT to an app's store until the bucket has a CORS rule, and today nothing on the platform sets one. Media roadmap stage 5 already assigns this to carlos media enable. This asks for that one piece now, because it does not depend on kind:media and it unblocks direct uploads for every app on the store.
Why now. rastrillo has decided (rastrillo#59, 2026-10-01) that uploads go straight to the bucket when the store is S3 and JavaScript is running:
- a presigned PUT to a staged key,
- then the app verifies,
- then the app promotes to the content-addressed key.
Oficina slides already does exactly this on rastrillo blobs. But on carloku the browser's PUT fails CORS unless someone sets the bucket's CORS by hand. Members doing that themselves would be working around the platform. And S3 CORS is bucket-wide with no prefix selector, so it belongs with whoever owns the bucket.
What the roadmap already specifies (stage 5, codex 23), which is enough to build from:
- The platform owns the bucket's CORS for the app's own hostnames.
- It merges with nothing: a bucket that already has CORS is refused until an operator clears it.
- It exposes
ETagand the multipart headers. - It removes the rule when the feature is disabled.
Open for the platform to decide:
- Whether this hangs off
carlos media enableor a store-level verb (for examplecarlos store cors), given stage 1 is not scheduled. - How custom domains join the allowed origins.
- Whether
PUTandPOSTare both allowed, orPUTonly. rastrillo's helper will use presignedPUT.
Related: #107 (media), and the image-transforms thread filed alongside this.