Conversation
| if let Ok(data) = frame.into_data() { | ||
| task::Poll::Ready(Some(Ok(data))) | ||
| } else { | ||
| task::Poll::Pending | ||
| } |
There was a problem hiding this comment.
i'm not sure this is correct. now that bodies yield Frame<T>'s, a body can yield either a data frame or a trailers frame, it seems like there is not a way to expose an equivalent data() method.
previously, Body::data() and Body::trailers() could delegate downwards to Body::poll_data() and Body::poll_trailers(), respectively. now, the trait provides a single Body::poll_frame() trait method, so there is not a clear poll function which this Data<'a, T> future can invoke.
this conditional block would discard a trailers frame, and additionally, it could cause a task to become deadlocked. see Poll::Pending, which states:
When a function returns Pending, the function must also ensure that the current task is scheduled to be awoken when progress can be made.
so, not only would the data yielded by the body not be accurately represented when this function is used, but additionally, it leaves the task in a state that violates the contract outlined by std.
i am sympathetic about the fact that the frame-oriented 1.0 interface causes some significant churn (see our work in linkerd/linkerd2#8733 for an example), but it is unfortunately incompatible with a data() method like this. i can't speak for the project myself, but i feel somewhat strongly as an onlooker that this change should not be pursued.
2 participants
I'm updating http-body from 0.4 to 1.0. The
data()method is not exists in new version.into_data_stream()is a substitute, however it makes too many diffs in my project. So i wish this convenient method, data(), to be saved in 1.0