Request (and Response) and trait objects

Currently, Request is generic over the body type. This is the primary type that libraries are expected to use when they require a Request value. Even if the library does not care about the body type (it only needs the head), it is expected to take a Request<?>. This can cause problems with trait objects.

Take the following trait. Implementations are expected to only require the head data.

trait Foo {
    fn foo<T>(&self, request: &Request<T>);
}

Because the trait fn has a generic, it is not possible to use as a trait object. If the trait is updated to:

trait Foo {
    fn foo(&self, request: &Request<()>);
}

Then the following function is unable to call foo:

fn some_fn<T>(&self, foo: &Foo, request: &Request<T>) {
}

Because, the request here is generic over the body type but the fn only takes a reference to the request, some_fn cannot convert &Request<T> -> &Request<()>.

Now, one option would be to provide request::Head which contains only the head components of the request and Request becomes:

struct Request<T> {
    head: Head,
    body: T,
}

This goes back to #22, #56 which decided against this approach. However, the issue I raised above was not considered.

Start by examining the generic Request API and the trait-object examples in the issue, then review the related discussions in #22 and #56. Compare the proposed Head split with the stated use case and establish an agreed API direction; done means the design decision and its impact on trait-object callers are resolved.