Provides a uniform access strategy to HTTP bodies in RAM, or buffered to a temporary file, and optionally memory mapped.
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.
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.
The following features may be enabled or disabled at build time. All are enabled by default.
BodyImage::mem_map support for memory mapping from
body-image-futio: Asynchronous HTTP integration with futures, http,
hyper, and tokio for
BodySink, for both client and server
A logical buffer of bytes, which may or may not be RAM resident.
A logical buffer of bytes, which may or may not be RAM resident, in the process of being written.
An HTTP request and response recording.
Extract of an HTTP response.
Extract of an HTTP request.
A collection of size limits and performance tuning constants. Setters are
A builder for
Error enumeration for
A set of HTTP Transfer- or Content-Encoding values.
Exploded representation of the possible
The crate version string.
Access by reference for HTTP request (via
Access by reference for HTTP request recording types.