a92f6f70e2
POST /api/v1/mangas and POST /api/v1/mangas/{id}/chapters now accept
multipart/form-data, gated by CurrentUser:
- /mangas: required `metadata` part (NewManga JSON) + optional `cover`
image part.
- /mangas/{id}/chapters: required `metadata` (NewChapter JSON) + one or
more `page` parts ordered by arrival. Returns 404 if the parent manga
doesn't exist, 409 on duplicate (manga_id, number).
MIME is sniffed via the `infer` crate (magic bytes), not the
client-supplied filename or Content-Type. Whitelist:
jpeg / png / webp / gif / avif. Anything else → 415
unsupported_media_type. The stored key's extension is derived from the
sniffed type so a "page1.png" that's actually a JPEG lands as `.jpg`.
Size cap is two-layer:
- Request body cap (config.max_request_bytes, default 200 MiB) enforced
by axum's DefaultBodyLimit before the handler sees the request.
- Per-image-part cap (config.max_file_bytes, default 20 MiB) enforced
after reading the part, so a single oversized image can't pass even
if the total request fits.
Storage keys follow the layout documented in CLAUDE.md:
- mangas/{manga_id}/cover.{ext}
- mangas/{manga_id}/chapters/{chapter_id}/pages/{nnnn}.{ext} (1-indexed).
AppError grows PayloadTooLarge/UnsupportedMediaType/ValidationFailed
(413 / 415 / 422). ValidationFailed carries a `details` JSON object the
client can use to highlight bad fields (e.g. {"title":"required"}).
Top-level matching in code() stays exhaustive.
Backend coverage in tests/api_uploads.rs (10 cases):
- create_manga_with_cover_stores_image — file is reachable via
/api/v1/files/{key} with the right Content-Type.
- create_manga_without_cover_leaves_path_null.
- create_manga_rejects_non_image_cover_with_415 — PDF claimed as png.
- create_manga_rejects_oversized_cover_with_413.
- create_chapter_with_pages_stores_each — extension derived from
sniffed MIME, files reachable in arrival order.
- create_chapter_rejects_when_no_pages_with_422 — details.page set.
- create_chapter_rejects_renamed_non_image_page → 415.
- create_chapter_returns_409_on_duplicate_number.
- create_chapter_requires_authentication → 401.
- create_chapter_under_unknown_manga_is_404.
Existing tests/api_mangas.rs is migrated to multipart; the create
response is now 201 Created. tests/common::MultipartBuilder builds the
body by hand so the test crate stays free of HTTP-client deps.
Frontend lib/api/mangas.ts: createManga now sends FormData (metadata +
optional cover Blob). Browser fills in the boundary header automatically.
Vitest asserts the FormData structure via FileReader (jsdom doesn't
implement Blob.text()).
E2E tests wait for the post-hydration nav-login link before
interacting with the login form, fixing a flake where pre-hydration
clicks would submit via the browser default and bypass our handler.
Lockstep version bump to 0.5.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mangalord
A self-hosted manga and comics reader. Browse, search, read, bookmark, and upload manga and chapters. The HTTP API is consumed by both the SvelteKit web UI and external bots/scripts that perform the same actions programmatically.
Stack
- Backend: Rust, axum, sqlx
- Database: Postgres 16
- Frontend: SvelteKit 2 (Svelte 5 runes), TypeScript, Vite
- File storage: pluggable
Storagetrait — local FS today, S3 (and friends) as future impls - Deploy: Docker Compose on a single server
Quick start
cp .env.example .env
docker compose up --build
- Frontend: http://localhost:3000
- API: http://localhost:8080/api
- API health: http://localhost:8080/api/health
Local development
Run only Postgres in Docker; run backend and frontend natively for fast iteration:
docker compose -f docker-compose.dev.yml up -d
# backend
cd backend
export DATABASE_URL=postgres://mangalord:mangalord@localhost:5432/mangalord
cargo run
# frontend (separate shell)
cd frontend
npm install
npm run dev
The Vite dev server proxies /api to http://localhost:8080.
Tests
This project is developed test-first. Tests live at three levels:
# Backend: unit (in-module) + integration (tests/, per-test DB via #[sqlx::test])
cd backend && cargo test
# Frontend: unit / module tests (Vitest)
cd frontend && npm test
# Frontend: end-to-end (Playwright; spins up dev server, mocks API by default)
cd frontend && npm run test:e2e
API surface
| Method | Path | Purpose |
|---|---|---|
| GET | /api/health |
Liveness |
| GET | /api/mangas |
List / search mangas |
| POST | /api/mangas |
Create a manga |
| GET | /api/mangas/{id} |
Get a manga |
| GET | /api/files/{key} |
Stream a blob (cover, chapter page) |
Chapters, uploads, and bookmarks are next — the patterns to extend are documented in CLAUDE.md.