hyper

hyper copied to clipboard

We temporarily renamed the old hyper::Body struct to hyper::body::Recv in #2966. That was to unblock #2839, since we wanted to use the name for the trait instead. But, the name should be properly considered.

The purpose of this type is: an implementation of Body to represent bodies received from a remote. So, the client side would see this in the Response, and the server side would see this in the Request. It is not meant to be constructed by users as a "default" implementation.

Some names I've seen or considered before:

• Recv
• RecvStream/RecvBody
• Streaming
• Incoming
• Remote
• Wire/FromWire

It might help to envision the type signature users will frequently see it as, such as Request<Streaming> (or insert any other name in there).

Pinging because you may have opinions about the name: @hawkw @LucioFranco @davidpdrsn.

Node.js uses IncomingMessage. Making the connection to Body clearer though would be good. Perhaps IncomingBody?

Assuming that the user would never construct these themselves then I like IncomingBody.

ReqBody?

It's the body of a Request for servers, but it's the body of Responses for the client.

ReqBody doesn't work well because on the client it would be the RespBody.

I like RecvBody. I think the -ing forms are odd for a 'static type name, and I think it should be a name that includes Body because that's what it's called in the HTTP standard.

IncomingBody sounds good then.

Another similar name/idea would be IngressBody. Is this always an http related body? If so, the name HttpBody may also be considered.

I think more explícit is better and because is a request and responde body, then i like HttpBody

I like the idea of hinting that it's a stream, I know for some it's confusing that you don't get the whole headers+body on the same await. So ~RecvStream,~ IncomingBody or something like BodyStream/StreamingBody would be my choice.

EDIT: On second thought, RecvStream name is too detached from the concept of HTTP Body.