1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
//! Streaming bodies for Requests and Responses //! //! For both [Clients](::client) and [Servers](::server), requests and //! responses use streaming bodies, instead of complete buffering. This //! allows applications to not use memory they don't need, and allows exerting //! back-pressure on connections by only reading when asked. //! //! There are two pieces to this in hyper: //! //! - The [`Payload`](body::Payload) trait the describes all possible bodies. hyper //! allows any body type that implements `Payload`, allowing applications to //! have fine-grained control over their streaming. //! - The [`Body`](Body) concrete type, which is an implementation of `Payload`, //! and returned by hyper as a "receive stream" (so, for server requests and //! client responses). It is also a decent default implementation if you don't //! have very custom needs of your send streams. pub use self::body::{Body, Sender}; pub use self::chunk::Chunk; pub use self::payload::Payload; mod body; mod chunk; mod payload; // The full_data API is not stable, so these types are to try to prevent // users from being able to: // // - Implment `__hyper_full_data` on their own Payloads. // - Call `__hyper_full_data` on any Payload. // // That's because to implement it, they need to name these types, and // they can't because they aren't exported. And to call it, they would // need to create one of these values, which they also can't. pub(crate) mod internal { #[allow(missing_debug_implementations)] pub struct FullDataArg(pub(crate) ()); #[allow(missing_debug_implementations)] pub struct FullDataRet<B>(pub(crate) Option<B>); } fn _assert_send_sync() { fn _assert_send<T: Send>() {} fn _assert_sync<T: Sync>() {} _assert_send::<Body>(); _assert_send::<Chunk>(); _assert_sync::<Chunk>(); }