multer-rs

multer is an async parser for multipart/form-data request bodies in Rust. It accepts any Stream of Bytes as input — not a specific web framework’s request type — so it plugs into any async Rust HTTP server or client, and is the multipart-parsing engine behind several Rust web frameworks including Rocket.

The library exposes a Multipart type for iterating over form fields asynchronously (next_field().await), with each Field giving access to name, filename, content type, and chunked byte data, plus optional JSON deserialization, configurable size limits/constraints, and Tokio AsyncRead integration behind feature flags.

What You Get

• A Multipart type that wraps any Stream<Item = Bytes> plus a boundary string and yields fields via next_field().await
• Per-field access to name, filename, MIME content type, headers, and chunked body data (field.chunk().await)
• Configurable SizeLimit and Constraints to cap total/per-field upload size and restrict allowed field names
• Optional JSON field deserialization (json feature) and Tokio AsyncRead adapter (tokio-io feature) for framework interop

Common Use Cases

• Parsing file uploads and form fields in a custom async Rust web server not tied to a specific framework’s multipart implementation
• Building a web framework’s or middleware’s multipart-handling layer on top of a stable, independently-tested parser
• Streaming large file uploads without buffering the entire request body in memory
• Enforcing upload size limits and field-name allowlists at the parser level before request handlers see the data

Under The Hood

Architecture — multipart.rs implements the top-level Multipart struct driving an internal state machine over the incoming byte stream, delegating boundary-detection to helpers.rs (which uses memchr for fast substring search) and header parsing to httparse; field.rs wraps each detected part as a Field exposing Content-Disposition metadata parsed in content_disposition.rs, while constraints.rs and size_limit.rs layer optional validation (allowed field names, max sizes) on top without touching the core parsing path, and buffer.rs manages the internal byte accumulation buffer between stream polls. Tech Stack — Rust 2018 edition using futures-util for the Stream abstraction (framework-agnostic), bytes for zero-copy buffer handling, httparse/http/mime for header and content-type parsing, encoding_rs for charset handling, and a spin-based mutex for synchronization without pulling in std::sync where avoidable; optional serde/serde_json (via the json feature) and tokio/tokio-util (via tokio-io) keep the default build minimal. Code Quality — the crate ships a fuzz/ directory for fuzz-testing the parser against malformed multipart input (a meaningful signal for a library that parses untrusted network data), plus an integration.rs test suite and example programs (parse_async_read.rs); it is stable and widely reused as the multipart engine inside other frameworks (e.g. Rocket), though upstream commit activity has slowed since the 3.1.0 release. API Design — the Multipart::new(stream, boundary) + while let Some(field) = multipart.next_field().await? loop is the same shape as iterating any async stream in Rust, keeping the learning curve low for anyone familiar with futures/tokio; framework-agnostic design means integrating it requires writing a small adapter to extract the byte stream and boundary from whatever HTTP library is in use.