Crate body_image
source ·Expand description
Provides a uniform access strategy to HTTP bodies in RAM, or buffered to a temporary file, and optionally memory mapped.
BodyImage
, BodySink
and supporting types provide a strategy for safely handling potentially
large HTTP request or response bodies without risk of allocation failure,
or the need to impose awkwardly low size limits in the face of high
concurrency. Tunables
size thresholds can be
used to decide when to accumulate the body in RAM vs. the filesystem,
including when the length is unknown in advance.
A Dialog
defines a complete HTTP request and
response recording, using BodyImage
for the request and response bodies
and http crate types for the headers and other components.
See the top-level (project workspace) README for additional rationale.
Optional Features
The following features may be enabled or disabled at build time. All are enabled by default.
mmap: Adds BodyImage::mem_map
support for memory mapping from FsRead
state.
Related Crates
barc: Body Archive container file reader and writer, for
serializing Dialog
records. See also barc-cli.
body-image-futio: Asynchronous HTTP integration with futures, http,
hyper 0.12.x., and tokio for BodyImage
/BodySink
, for both client
and server use.
Structs
BodyImage
.Tuner
Tunables
. Invariants are asserted in the various setters
and finish
.Enums
BodyImage
and BodySink
types. This may be
extended in the future so exhaustive matching is gently discouraged with
an unused variant.Read
reference for a BodyImage
in any state.Display
/ToString
representation is as per the HTTP header value.BodyImage
states, obtained via
BodyImage::explode
.Statics
Traits
RequestRecorded
) and response
recording types.