Provides a uniform access strategy to HTTP bodies in RAM, or buffered to a temporary file, and optionally memory mapped.
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
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 0.12.x., and tokio for
BodySink, for both client
and server use.
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. This is the write-side corollary to
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 subset of supported HTTP Transfer or Content-Encoding values. The
Exploded representation of the possible
The crate version string.
Access by reference for HTTP request (via
Access by reference for HTTP request recording types.