docs(cryptify): document HTTP Range support and Accept-Ranges on /filedownload

[dobby-coder]

Cryptify's GET /filedownload/{uuid} endpoint now honours inbound Range headers and advertises Accept-Ranges: bytes, enabling resumable downloads in browsers. Previously Rocket 0.5's FileServer ignored Range and always returned a plain 200 with the full body, which made browsers disable the resume button on flaky multi-GB downloads.

Source PR

encryption4all/cryptify#154 — fix: HTTP Range support on /filedownload (merged 2026-05-13). Closes encryption4all/cryptify#153.

What needs documenting

In docs/repos/cryptify.md (and possibly docs/guide/architecture.md, which already lists /filedownload/{uuid} in its endpoint table), expand the description of GET /filedownload/{uuid} to mention:

• Always sets Accept-Ranges: bytes.
• With no Range header: 200 OK with Content-Length and the full body.
• With a single Range header (bytes=N-M, bytes=N-, or bytes=-N): 206 Partial Content with Content-Range: bytes start-end/total and the requested slice.
• Unsatisfiable or malformed ranges: 416 Range Not Satisfiable with Content-Range: bytes */total.
• Multi-range (multipart/byteranges) is intentionally unsupported.

Also note in the CORS-related section that Range is now in the allowed_headers list so browser fetch calls can send it.

Verification

• Cross-check src/main.rs at the merge commit of cryptify#154.
• Run npx vitepress build docs.
• Style: align with postguard-docs/CLAUDE.md (no em dashes, minimal bold, no banned words).

[dobby-coder]

/dobby

[dobby-coder]

This agent sees the task! Dobby will gladly trace cryptify#154, peek at the merge commit's src/main.rs, and update docs/repos/cryptify.md (plus the architecture endpoint table if needed) with the new Range/Accept-Ranges behaviour. House-elf will keep the style plain and the diff small. Plan up next.

[dobby-coder]

Plan

Source PR verified: encryption4all/cryptify#154 merged at b1eff690eae096d4cec55e7dbf323d8d0c3d74c0. Confirmed in src/main.rs:

• parse_range_header + download handler at lines ~959-1083 set Accept-Ranges: bytes, return 206 with Content-Range for single ranges, 416 for unsatisfiable, plain 200 otherwise. Multi-range comma-separated input is rejected.
• CORS allowed_headers list at lines ~1135-1144 includes Range.

Files to change:

1. docs/repos/cryptify.md — expand the GET /filedownload/{uuid} bullet (currently line ~100) into a short subsection covering the four response shapes (200 full, 206 partial, 416 unsatisfiable, multi-range unsupported), and note that Range joins Authorization/Content-Type/Content-Range/CryptifyToken/X-Recovery-Token in CORS allowed_headers. Pin source links to the merge commit with line ranges.
2. docs/guide/architecture.md — update the endpoint table row for GET /filedownload/{uuid} to mention Range/Accept-Ranges in one short sentence, link to the new docs subsection.

Style: plain English, no em dashes, no banned words, no bold, minimal prose. New subsection sits next to the existing chunk-upload docs so the API page reads in order.

Verification: npx vitepress build docs must succeed; spot-check rendered output in docs/.vitepress/dist/repos/cryptify.html.

Out of scope: client-side resume UX (already tracked at encryption4all/postguard-website#138).