Outcome of spooling a streaming request body to disk: the path of the
freshly created tempfile, the total byte count, and the MD5 hash of
the bytes (lowercase hex, the form S3 uses for ETag).
A response body. Most handlers return ResponseBody::Bytes built from
an in-memory Bytes buffer; the File variant
exists so large disk-backed objects can be streamed straight from the
filesystem to the HTTP body without being materialized into RAM. The file
handle is opened by the service handler while it still holds the
per-bucket read guard, so the reader sees a consistent inode even if a
concurrent PUT/DELETE renames or unlinks the path before dispatch streams
the body.
Drain a streaming request body into a single Bytes buffer with no
upper bound. Used by handlers that legitimately need the whole payload
in memory (small JSON-shaped requests that happened to land on a
streaming route, e.g. ECR mount PUT with no body). Heavy uploads
(S3 PutObject / UploadPart, ECR blob PATCH/PUT) take the streaming
spool path via spool_request_stream instead. The dispatch-level
cap (FAKECLOUD_MAX_REQUEST_BODY_BYTES) does not apply to streaming
routes; this helper exists so a service handler that knows the
payload is small can buffer without dragging in axum itself.
Stream a request body to a tempfile on disk while computing its MD5
and length on the fly. The body is never materialized into a
single Bytes buffer; chunks flow from hyper -> Tokio file in
constant memory. A 1 GiB PutObject moves through this function with
peak resident memory bounded by hyper’s per-frame buffer.
Streaming request body kept alongside the buffered body: Bytes. Set
by dispatch only for routes that opt into streaming (S3 PutObject /
UploadPart, ECR OCI blob upload PATCH/PUT). Service handlers call
AwsRequest::take_body_stream to consume the raw stream without
buffering the entire payload into memory; non-streaming services
keep using req.body (which is empty Bytes for streaming routes).