tower-rs/tower-hyper

A hyper based tower transport layer.

tower-hyper's Issues

Migrate to tower-util

Failed to compile with: error[E0034]: multiple applicable items in scope

Tested with
stable rustc 1.34.2
nightly rustc 1.36.0-nightly

error[E0034]: multiple applicable items in scope
  --> src\body.rs:65:15
   |
65 |         inner.poll_data::<hyper::Body>()
   |               ^^^^^^^^^ multiple `poll_data` found
   |
   = note: candidate #1 is defined in an impl of the trait `hyper::body::payload::Payload` for the type `hyper::body::body::Body`
   = note: candidate #2 is defined in an impl of the trait `http_body::Body` for the type `hyper::body::body::Body`

Migrate to tower-util::MakeService

Prepare for release

Simple checklist to get tower-hyper out on crates.

• Figure out HttpConnection
• Review api

cc @carllerche @seanmonstar

Why is Http<OtherExecutor> not supported

I'm confused why Http<DefaultExecutor> is the only choise in Server::serve_with. Is there any special reasons to forbid Http<tokio_threadpool::Sender>?

Private trait in Service implementation bounds for Connect

The implementation of Service for Connect features a type parameter bound of ConnectExecutor, which is a private trait (leading to a rabbit hole of prerequisites and parameter bounds). This makes it practically impossible to use Connect with a generic executor, as the required bound for the executor type is an internal detail of tower-hyper.

Use a single hyper connection as service

If I manually construct a connection like

tower_hyper::client::Builder::new()
                            .http2_only(true)
                            .handshake(sock)
                            .and_then(|(sender, conn)| {
                                    ... spawn conn...
                                    let conn = Connection::new(sender); // private not possible
                                    conn.call(....)

there's no way to convert that (sender) into tower_hyper::Connection,
since the method is pub (super). Is that intended?

Usage of log considered harmful

tower-hyper uses macros from the log crate in asynchronous code internally. This is inflexible and problematic for a library crate: the logger instance of log is set globally in the application, whose developers might not be aware of logging going on in the library, while many popular logger implementations are blocking.

If logging must be done, it would be much better for task-bound structures such as Connect to incorporate an optional, application-settable structural logging context in the style of slog. The API users would then be aware of the logging, be able to add contextual information per instance, and be able to supply a non-blocking frontend such as slog-async.

Move to `hyper::Body` from `tower_hyper::Body`

Allow get HttpExtra from Connection

I am building a connection pool and want to use different scheduling policies for different protocols and addresses.

The current Connection does not provide the information I want, we can make Connection return an HttpExtra?

ALPN support

Currently the tower-hyper client is unable to get ALPN negotiation results from Connector.

We should try to support this. For example, add a trait to <C as MakeConnection<A>>::Response to get negotiation result of ALPN.

use http::version::Version;

trait Alpn {
    fn get_version(&self) -> Version;
}


impl<A, B, C> Service<A> for Connect<A, B, C>
where
    C: MakeConnection<A> + 'static,
    B: Payload + 'static,
    C::Response: Alpn + Send + 'static,
{
    // ...
}

// ...

            self.builder.http2_only(io.get_version() == Version::HTTP_2);
            let handshake = self.builder.handshake(io);
            self.state = State::Handshake(handshake);

// ...

I don't think this is a elegant solution, maybe you have a better idea. :)

Compatibility with tower-grpc

Would be great to use this as the connection type in tower-grpc client/servers.

Potentially just requires some magic to implement Payload for tower_grpc::BoxBody?