Closed general

issue --file: route video extensions through the presigned direct-to-bucket flow

Colby Knox · 2mo ago ·closed by Colby Knox

The wiki now supports video attachments on issues (adom/wiki#110) via a direct-to-bucket presigned flow the CLI should adopt for --file when the extension is a video (mp4, webm, mov, m4v, mkv):

  1. POST /api/pages///attachments/videos/presign with { filename, bytes } (bytes = exact file size; cap 256MB, refused 413 over). Returns { token, upload_url, content_type, expires_s }.
  2. PUT the raw file to upload_url with Content-Type: . The signature binds the exact content-length and type, so send precisely what was declared. 15 minute expiry.
  3. POST .../attachments/videos/confirm with { token, filename }. Returns the same shape as the multipart upload (url, filename, content_type video/*), embed as name like other files.

Multipart uploads of video extensions refuse with code VIDEO_USE_PRESIGN carrying max_bytes in data, so you can key the routing on the error too. Videos are not content-addressed (the token is random); do not expect dedup.

1 Reply

Colby Knox · 2mo ago

Shipped in 1.0.82, live as latest, and live-tested against the staging endpoints end to end (a .mp4 presigned, PUT direct to the bucket with the bound Content-Type, confirmed, embedded on an issue as [clip.mp4](/attachments/kcknox/...)).

Implementation notes worth recording:

  • --file routes mp4/webm/mov/m4v/mkv through presign -> PUT -> confirm automatically everywhere --file exists (issue create/comment/edit, pr comment, page attach). The confirm response being multipart-shaped meant zero changes to the embed path: videos land as plain [name](url) links like any other file.
  • The presign PUT deliberately sends NO auth header: the signature is the authorization and the host is a bucket. Recorded in the client as the one sanctioned exception to the never-talk-to-bucket-hostnames rule, since the server hands us this URL for exactly one upload.
  • Local pre-validation: the 256MB cap fails instantly offline; the exact byte count read is the byte count declared, so the signature's length binding can only break if the file changes between presign and PUT, and the error for that names the ~15 minute expiry and says to just re-run.
  • VIDEO_USE_PRESIGN renders first-class (data.max_bytes plus the three-step recipe) as the belt for raw-api callers and pre-1.0.82 CLIs, with self-update as the cmd.
  • No-dedup noted in code and docs per the spec: the token is random, videos are not content-addressed.

Log in to reply.