Is there a way to hook/enumerate that a Body has ended?

[AshleySchaeffer]

I'd like to do further computations upon the completion of sending/receiving a hyper Body.

I'm not 100% sure what the best approach to this is after playing with available methods and some debugging.

Anyone got any ideas?

[seanmonstar]

When receiving a body, if you're polling the data of it, you can just trigger a computation once it returns None. Sending would require you to instrument an impl HttpBody. The tower_http::trace body wrapper might help show you. It wraps any other body type with potential callbacks as chunks are emitted and as the body ends.

[AshleySchaeffer]

Thanks for replying so quickly.

I have a setup that's polling a receiving Body and it never seems to return None. Would you mind providing a crude example for my sanity? I've been going at this all day.

[AshleySchaeffer]

I'm also a bit wary of implementing my own variant of Body as it looks like there's some client related stuff in the hyper one that might be important (delayed EOF).

How safe is it to implement my own Body?

[seanmonstar]

At the bottom of the client guide, you can see how to iterate the data of a body, and when that while let Some(..) loop finishes, the body has finished.

It's safe to implement the hyper::body::HttpBody trait. You don't need to worry about the internal stuff of the hyper::Body struct, it's doing special stuff.

[AshleySchaeffer]

Thank you. I think I'll try a wrapper and see if I can use it for both sending receiving.

To be clear, and I'll stop nagging after this, will I definitely not see any differences between hyper::Body and my own? Sorry to question it again, I'm mainly concerned by this stuff (see comment). I am using the hyper client:

hyper/src/body/body.rs

Lines 67 to 77 in 740654e

	struct Extra {
	/// Allow the client to pass a future to delay the `Body` from returning
	/// EOF. This allows the `Client` to try to put the idle connection
	/// back into the pool before the body is "finished".
	///
	/// The reason for this is so that creating a new request after finishing
	/// streaming the body of a response could sometimes result in creating
	/// a brand new connection, since the pool didn't know about the idle
	/// connection yet.
	delayed_eof: Option<DelayEof>,
	}