Request (and Response) and trait objects

[carllerche]

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.

[seanmonstar]

What sort of trait needs this? And is the full head actually needed, or just the URI or headers?

I wonder if we can have some sort of fn head(&self) -> &Request<()> accessor...

[carllerche]

I'm writing a trait that takes the request head and extracts data from it.

Of course, there are ugly ways of working around the issue. The least ugly would probably be for the library to define a struct like:

struct Head<'a> {
    method: &Method,
    uri: &Uri,
    ...
}

I'm mostly bring it up as it seems like a flaw in the original assumptions.

I wonder if we can have some sort of fn head(&self) -> &Request<()> accessor...

That could work, but I don't know if this can be provided safely.