Repository navigation
Split apart the Body type #2345
Description
Activity
As a consumer, I like this proposal.
hyper::body::Empty: an empty body, yielding no data or trailers. Since it never yields data, itsBuftype could even be some enumNeverBuf {}.I don't want to jinx this, but it's possible that
!might get stabilized with rust-lang/rust#79366. I don't think it'll be stable in time for Hyper 0.14, but there's a chance it might be stable in time for Hyper 0.15 (if planned).Does this imply that the Client type can drop its body type parameter? That'd be quite nice for reasons even beyond this issue, like allowing non
'staticbodies.I don't see how the client would drop its body type parameter... it still needs to know what kind of bodies you expect to send.
I like this proposal, I'd also consider adding a
GenericBodywhich is an enum of all of the bodies + the boxed one? We may also want to provide utils likeEitherBodyto compose them. Overall, I am a fan of this, no major nits.Would be nice to still be able to use all types at once, as @LucioFranco said. I belive most of apps mix those, eg.
Fullfor data,Streamingfor SSE etc. If body type goes into server template parameter, it would be a bit harder to return multi-variant version. Boxing is an option, but still requires some allocations. Having enum of three types doesn't sound bad.Something I didn't consider when responding to this initially: what implications, if any, does this proposed change have for h2-style patterns where the initial handshake request has a body of
()but the client subsequently expected to write to a stream handle?If you expect different requests to have different body behaviors, you can use a body type that captures that.
So, it does seem like this is desirable, but I'm going to punt to the next milestone, since proposing this right when 0.14 was almost ready is kinda late.
6 remaining items
The
http-body-utilcrate now has many of these variants. We likely won't re-export directly from hyper, since that util crate is less stable. Next steps for hyper 1.0 are to remove the internal variants ofhyper::Body, and replace their usage in tests and examples with those fromhttp-body-util.Reacted by Lucio Franco and Xuanwo
This has been suggested before: the current trait
hyper::body::HttpBodyshould be renamed tohyper::Body, and the existing structhyper::Bodyshould be split up into more descriptive implementations. I'm coming around to that idea, so here's the full proposal.Proposal
hyper::body::HttpBodytohyper::Bodyhyper::Bodytype:hyper::body::Empty: an empty body, yielding no data or trailers. Since it never yields data, itsBuftype could even be someenum NeverBuf {}.hyper::body::Full: the full body, able to yield 1 data buffer (whathyper::Body::from(buf)is in 0.13).hyper::body::Streaming: the streaming bodies received from a remote over HTTP/1 or 2.hyper::body::BoxBodyA client response would then be
Response<Streaming>(as would a serverRequest<Streaming>), since they are streamed from the connection. Hopefully, this should make the intent clearer when you have aRequest<Empty>orResponse<Full>, instead of justRequest<Body>.Status: Accepted
Progress
streamvariantOncevariantbody::Sendertype andBody::channel()constructor private.BodytoRecvtemporarilyHttpBodyre-export toBodyRecvbody type #2971hyper::bodymodule with how to use different body types #3103