http-ferry
A resumable, checksum-verified, streaming byte-transfer engine: pull bytes from
an HTTP source and push them into a pluggable sink, hashing as you go. One sink
ships in the box (local file); another (S3 multipart upload) lives behind the
s3 feature. The caller's own item type rides through untouched, the way
reqwest hands your response back to you.
The crate knows nothing about any specific service — you bring the URLs, the
auth, and (optionally) your own sink. It was extracted from archive-it-client,
which uses it to download WASAPI WARCs to disk or S3.
The name: the HTTP side is the source and Sink is the destination, so the
crate ferries bytes from one to the other.
What it does
- Resumable downloads over HTTP range requests, including the awkward case
where a server ignores
Rangeand replies200instead of206(the sink is restarted and the byte counter resets). - Integrity verification with a pluggable
Checksum(sha1 / md5). The engine hashes the stream with the matching algorithm and fails on mismatch. - Skip-on-exists: a sink can report the destination already holds the file
(by checksum, or by size when no checksum is supplied) and the engine yields
Skippedwithout fetching a byte. - Progress + per-item error isolation: a
StreamofOutcomeevents; one bad file in a batch yieldsFailedand the stream continues. - Retry with exponential backoff, both at request setup and mid-stream.
Core concepts
| Type | Role |
|---|---|
Downloader |
Owns the HTTP client, retry policy, and a request-customization hook (where you inject auth). |
Transfer<M> |
One unit of work: size, optional checksum, destination name, and your opaque meta. |
Target<'a> |
The borrowed view a sink sees: name, size, checksum. No URL, no meta — sinks are domain-agnostic. |
Sink / SinkFactory |
Where bytes go. Implement these to add a destination (disk, S3, GCS, a database BLOB…). |
Outcome<M, L> |
Per-item result stream: Downloaded / Skipped / Progress / Failed / StreamFailed. |
drive(..) |
The one driver. Pulls Transfers, resolves each source URL, builds a sink, runs the download. |
The engine reads only three things off each item — size, checksum, name —
so your rich type (M) is never inspected; it is cloned into Progress events
and handed back in the terminal Outcome.
Cargo features
s3(off by default) — the S3 multipart-upload sink in thes3module. It pulls in the wholeaws-sdk-s3dependency tree, so consumers who only download to disk don't pay for it. Enable withfeatures = ["s3"].
Usage
Wire a Downloader, hand drive a stream of Transfers, a closure that
resolves each item's source URL, and a SinkFactory:
use Duration;
use StreamExt;
use ;
// 1. An HTTP layer. The `customize` closure is for your auth — inject a bearer
// token, basic auth, signed headers, or nothing.
let token = var?;
let downloader = new;
// 2. A stream of work items. `meta` is whatever you want back in the outcome.
let items = iter;
// 3. Drive it: resolve each item's URL, write into ./out via the local sink.
// `create_all` makes the destination dir up front (it must already exist).
let mut out = pin!;
while let Some = out.next.await
Adding a destination
Implement Sink (per-file state machine) and SinkFactory (builds one sink
per item). The engine calls prepare once, then write_chunk repeatedly, then
finalize — or restart if the server forced a fresh download mid-stream.
use ;
Location types implement DownloadLocation so the engine can render where a
file went. To get Display on the outcomes, implement Label on your meta
type M (it supplies the filename used in log lines).
Design notes
- Auth is a closure, not a credential type.
Downloadernever names "basic auth" or "bearer token" — the consumer supplies aFn(RequestBuilder) -> RequestBuilder. This keeps the engine free of any service's auth model. - URL resolution is a per-item closure passed to
drive. Resolution can fail per item (yielding a non-fatalFailed) without tearing down the stream; a failure pulling the next item from the source yields a fatalStreamFailed. - Caller errors flow in through
Error::Source. The resolver and the input item stream produce the caller's error type. The engine type-erases them throughSource(Box<dyn Error + Send + Sync>), so it never needs to know a consumer's domain errors; callers recover the original bydowncast. - No auto-abort of interrupted uploads. Rust has no
AsyncDrop, so a sink that leaves server-side state (e.g. an S3 multipart upload) documents how to garbage-collect it rather than attempting brittle cleanup on drop. The S3 sink also defersCreateMultipartUploadto the first byte, so a source error before any data arrives leaves nothing behind.