Initial HTTP/2 support for Client and Server #1432
Conversation
seanmonstar
force-pushed
the
h2
branch
9 times, most recently
from
898a404
to
889f916
Compare
|
I think this is rather usable. There's some "integration" tests that use the full stack, client and server, and some basic cases are passing. I still don't feel the most confident about the client pool changes, but this could probably be merge this week. |
seanmonstar
force-pushed
the
h2
branch
4 times, most recently
from
41d6502
to
280c3f2
Compare
src/client/mod.rs
Outdated
| _ => { | ||
|
|
||
| } | ||
| } |
There was a problem hiding this comment.
@seanmonstar, Just randomly stumbled upon this repo. I think there's a way to simplify this if I'm not missing anything:
match (self.version, *version) {
(Ver::Http1, _) if *version != HttpVersion::Http10 && *version != HttpVersion::Http11 => {
*version = HttpVersion::Http11;
},
_ => {},
}
src/proto/h2/mod.rs
Outdated
| } | ||
| } | ||
|
|
||
| // body adpaters used by both Client and Server |
src/proto/h2/mod.rs
Outdated
| fn poll(&mut self) -> Poll<Self::Item, Self::Error> { | ||
| loop { | ||
| // TODO: make use of flow control on SendStream | ||
| // If you're looking at this and thinking of tryig to fix this TODO, |
|
Is this supposed to work together with the latest version of This is the (HTTP 1 only) code: Or is this simply a version mismatch that could be resolved with a |
|
@dbrgn that's because hyper-tls is depending on the crates.io version. You'll need to put |
|
Been running this on production for a couple of weeks with pretty big loads. Fast and works nicely, but some bugs might be worth to acknowledge if anybody else is testing... There is something fishy how hyper manages dead connections. It the remote end drops the connection, hyper gives a connection error and after that just silently sucks every request into the limbo. In other cases the connection just doesn't answer at all, but at least we can trigger a timeout and restart the connection. P.S. if anybody wants to debug the h2/hyper with Apple pushes, all help is appreciated! https://github.com/pimeys/apns2 |
Thanks! I had to do this: And then: |
|
Edit: Disregard the comment below, it doesn't have anything to do with Hyper. Sorry! I believe this is a problem with hyper and not with apns2: reown-com/a2#6 The application in question is a HTTP1 server with async Hyper, that uses a HTTP2 client to connect to APNS. Simplified code: impl Service for PushHandler {
// Boilerplate for hooking up hyper's server types
type Request = Request;
type Response = Response;
type Error = HyperError;
// The future representing the eventual response
type Future = BoxedFuture<Self::Response, Self::Error>;
fn call(&self, req: Request) -> Self::Future {
// ...
let apns_future = apns::send_push(...);
boxed!(apns_future)
}
}For some reason the h2 connection to the server is immediately closed. In the log I can find this line:
This is the full log: Could this be a bad interaction between h1 server and h2 client? |
|
I've just updated this branch with a rebasing to master (and minor fixes otherwise). If you were depending on the previous code somehow, I've pushed that to the |
This starts to add HTTP/2 support to hyper in 0.12.
So far, this only adds support for prior knowledge HTTP/2. ALPN and HTTP/1 upgrades would be later additions.
Client
The Client pool has been modified to try to only use a single connection when connecting over HTTP/2. However, it's farther hacky, and in general, the pool module could be tossed out and tried again at some later date.
In this PR, the Client determines whether to use HTTP/1 or HTTP/2 based setting
Builder::http2_only().Server
The server cannot so far try to detect if incoming requests are HTTP/1 or HTTP/2, and instead requires that to be set via
Http::http2_only().If you're showing up wanting to try this out, you need this in your
Cargo.toml:And then, if using the client:
If using the server:
cc #304