#http3

The days are growing longer up here, and work to make hyper better and better continues onwards!

There was some particularly exciting releases, and a bunch of conversations had in March 2023.

hyper 1.0

Preparing users for upgrading to 1.0

One of the important parts of the hyper 1.0 polish period is making sure upgrading from 0.14 to 1.0 is as smooth as we can make it. hyper v0.14.25 is here to help. @kxt and @oddgrd backported the client and server APIs from 1.0, and added opt-in deprecation messages to help you be ready to upgrade. The deprecation warnings are meant to help you, not to annoy you.

You can enable them to see where you can start preparing your code now:

[dependencies] # besides whatever other features you've enabled... hyper = { verion = "0.14.25", features = ["backports", "deprecated"] }

RC4 discussions

We've been discussing how to wrap up the last couple of changes for 1.0, to put out an RC4 to bake some. We have some decent answers, and can get to work.

hyper's own Service trait will change from &mut self to &self. This better aligns with reality, as most services already need to share state behind some synchronization mechanism, and needing to &mut self in the method call doesn't help.

hyper will use its own IO traits with forwards-compatibility in mind. We want to be able to support both poll-based and completion-based (think epoll vs io-uring) IO models.

HTTP/3

We're working on HTTP/3 in a separate crate, h3, with the goal of fitting it into hyper.

reqwest includes experimental HTTP/3 support

With reqwest v0.11.15, you can try out HTTP/3, on the client side, in reqwest right now! It's currently experimental, which means a couple things: it might not work perfectly. Let us know! It also might be disabled in new patches, as we fiddle with it. Lastly, you need to more explicitly opt-in to the instability.

That means that besides enabling the http3 feature from your Cargo.toml, you also need to pass RUSTFLAGS="--cfg reqwest_unstable" to the compilation job.

Huge thanks to @kckeiks for integrating h3 into reqwest!

h3-quinn upgraded to Quinn 0.9

We found a way to upgrade h3-quinn, using stream::unfold and BoxStream.

The h3 crate tries to be generic over any QUIC implementation. The h3-quinn crate implements the h3::quic traits for the Quinn crate. The traits currently use poll-based methods (async function in traits isn't stable yet, and they also wouldn't allow polling multiple things at the same time). Newer Quinn embraced using async fn on its types, instead of returning named futures, which is very fair thing to do. But it did make it hard to figure out how to implement poll-based methods over async fns.

I realized we could do a async-move-dance to solve this. We make an async move block, moving in the type and awaiting the future, which then returns a tuple of the original type and the return value. @Ralith made the suggestion to use stream::unfold, which streamlines that pattern. Then @inflation quickly wrote it up, and we were able to upgrade to Quinn v0.9.

Contribute

After recapping the 2022 year, here's what the amazing contributors have been doing to make hyper ever better during January and February of 2023.

Releases

hyper v0.14.24: fixes some expect-continue behavior, and reduces the internal max allocation in to_bytes.

h2 v0.3.16: adds a missing piece for Extended CONNECT, and several bug fixes (memory reduction, panics)

reqwest v0.11.14: adds Proxy::no_proxy(url) that works like the NO_PROXY environment variable, and several internal optimizations reducing copies and memory allocations.

tower-http v0.4.0: a new decompression layer for Requests, ServeDir and ServeFile now translates IO errors into Responses, and adds a more flexible ValidateRequest layer.

hyper 1.0

We released RC3, which fixed up some missing pieces in the API. Places needing an Executor now ask for one, and we added hyper::rt::bounds to publicly expose nameable but future-proof Executor trait "aliases", so libraries building on top of hyper can use them as bounds. We also added a few state getters for SendRequest which were needed for the next exciting part.

The higher-level pooling Client from 0.14.x has been ported to hyper-util. This was the most common blocker preventing people from trying out the release candidates. You can now use the legacy::Client with hyper 1.0.0-rc.3, and have the normal connecting/pooling client experience you're used to (see the example).

We're still in the hyper polish period 💅. There's still a little bit of time left to get us your feedback! It's the most important part of this period. Or join us in one of the four polish areas (or help lead one)! You can also come chat with us about anything.

We took some extra time to focus on RC4, which has the last few breaking changes to go. Likely, hyper will vendor it's own IO traits, and change Service::call to be &self instead of &mut self. See the related issues if you have feedback.

The extra time will also allow us to investigate having a security review done for 1.0, to prevent any gotchas.

HTTP/3

We're working on HTTP/3 in a separate crate, h3, with the goal of fitting it into hyper.

Quite the eventful year! With 2022 over1, I want to take some time highlight what's happened in hyper and the immediately surrounding landscape.

A quick personal note, I wrote much more this year!2 Yay!

hyper

Let's start with some general things about hyper.

On the human side, there were 62 unique contributors to hyper in 2022. We added 1 more collaborator and 2 triagers, and even defined what those roles even mean.

In an effort to share the lovely work those humans do, I started writing monthly hyper updates.

And we celebrated 10 thousand stars this year! ⭐

hyper 1.0

As I mentioned in last year's review, 2022 was the year we began to prepare to release a stable 1.0 of hyper.

We started with a v1.0 timeline (of which we're in the final steps). After much discussion with users, we put into writing hyper's VISION, which defined where we were going. Shortly aftewards came the v1.0 ROADMAP, outlining how to get there.

And then, a summer flurry of coding and hairy diffs.

On the other side, late last year, we published v1.0.0-rc.1. This represented the likely working library that we'd like set down into a stable parking spot for a while. While people check it out and give us feedback, we entered the hyper polish period, making sure everything feels good. That's where we still are, for a short period more.

You can follow along on the project board, and specifically the 1.0 meta issue ties together non-issue related details.

hyper in curl

The work to make hyper an HTTP backend in curl from last year continued throughout this year. There's just a few remaining tests in curl's large HTTP suite that didn't work when hyper is enabled. Several wonderful people showed up to dig in and find out exactly why.

To try to empower others to do, I wrote up a help-us-finish guide, explaining step-by-step how anyone could help us finish this all-important work. Later in the year, I streamed a hyper-in-curl debug session, where you could watch me follow the guide, and then bash the keyboard randomly while trying to understand what the issue is. You can still watch the recording, or see these details about what test was solved and the pull requests that came out of it.

I also joined Daniel Stenberg virtually by presenting about hyper in curl at curl-up 2022.

h3

We've been working on the h3 crate, providing HTTP/3 that is generic over any QUIC implementation, with the goal of integrating into hyper directly. The repository has had a working server and client which already interoperates with other implementations.

I've written about it in the monthly updates, but here's some highlights I'm excited about:

We added 3 new collaborators who have been driving the work: @eagr, @g2p, and @Ruben2424.

@stammw implemented graceful shutdown for the server and the client.

@Ruben2424 added GREASE support via an default-on option which sends random reserved identifiers, such as frames, settings and streams, to help prevent ossification that would make future extensions harder.

@eagr made it so we now track compliance with the HTTP/3 specifications, by using special comments that are compared with the spec text, and it even outputs a report updated as part of our continuous integration.

@Ruben2424 also added h3spec to CI, and fixed the missing pieces it noticed.

@g2p documented the entire API.

While there's still specific work that can be done on the h3 crate itself, it's time to consider next steps to get it into user hands. To that end, there's even a pull request for reqwest to use h3! There's just some details to work out around publishing unstable versions so reqwest can depend on it. We hope this experimental support will help us iron out any usage annoyances, so we can start landing it in hyper proper.

tower

While tower isn't tied to hyper, we've always meant for people to easily combine the two libraries to make powerful, opinionated HTTP stacks.

In the later half of the year, we started having discussions about making tower easier. Up until now, it has mostly felt like expert mode. But if done right, we shouldn't be telling users "no, you don't hold it that way" when they try to implement retries slightly wrong and storm their servers. So, to that end, Lucio put together a big issue outlining how we can make retries better.

Another discussion started about the path to tower 1.0. This brought some interesting questions around how Service handles backpressure, whether we could make that any better. Certainly, something else we would want to consider is if Service can make use of async fn in traits.

The tower-http repository continued to see additions. Mostly middleware that are specific to HTTP that many people would find beneficial, such as RequestBodyLimit, RequestBodyTimeout, ResponseBodyTimeout, and ValidateRequest.

I've also kicked around the idea loosely about cracking open the reqwest crate, and turning its various features into tower middleware. Then, reqwest is just a single opinionated way to build up a client stack. The community would be more empowered to customize the order of layers, adding or removing or swapping, and still have the power that they come to expect from using reqwest.

What are some possiblities in 2023?

Besides launch hyper 1.0, of course.

These are are all things that many people have asked for, and I'd like to see done. But realistically, most will require help from you!

Improved middleware

HTTP/3 in hyper

Tracing and Metrics

h2 performance improvements

An even-lower level http1 codec crate

Tower-ify reqwest

I'll likely be focused at the top of that list, but would welcome anyone interested jumping into an issue (or discussing on Discord if you prefer). Really, the biggest success would be empowering others to be the leaders and owners on these things. Do you want to be one of them?

Sorry for the delay, illness struck right at the beginning of the year. ↩︎

The northern hemisphere starts to cool, the trees shed their leaves to conserve energy, cultured fans watch the quadrennial football tournament, and some magnificient contributors stay warm by continuing to make hyper ever better!

Releases

hyper v0.14.23

@jfourie1 found and fixed a nasty bug in hyper's HTTP/2 client dispatcher, which could result in a stalled connection under high concurrency.

reqwest v0.11.13

The headline addition is a ClientBuilder::dns_resolver(), which now allows users to implement completely custom DNS resolvers for reqwest to use.

hyper 1.0

With the release of rc1 last month, I wrote about how we're now in the hyper polish period 💅.

@programatik29 volunteered to co-lead the util area. After many contributions to get us to rc1, @oddgrd joined us to lead the docs area. @vi noticed that the HTTP/2 client SendRequest should implement Clone.

We still eagerly welcome you trying out the release candidate and providing us feedback. It's the most important part of this period. Or join us in one of the four polish areas (or help lead one)! You can also come chat with us about anything.

hyper in curl

I fixed curl's c-hyper.c to classify headers from CONNECT and 1xx responses as such, making two more unit tests pass. I streamed the process, in case you'd find it helpful to watch someone who mainly writes Rust flounder around debugging and fixing C. You can try it too!

HTTP/3

We're working on HTTP/3 in a separate crate, h3, with the goal of fitting it into hyper.

@eagr made it so recv_trailers doesn't require holding onto the SendStream side. @g2p cleaned up a huge swath of clippy errors.

@g2p and @Ruben2424 joined as h3 collaborators, thanks to their excellent and continued work!

Tower

Tower (and tower-http) are a protocol-agnostic RPC framework with middleware, and they combine nicely with hyper.

@alexrudy added a new BoxCloneServiceLayer, and @leoyvens fixed a couple bugs in CallAll. @davidpdrsn made BoxService implement Sync.

As the leaves change and fall, our wonderful contributors continue to make hyper ever better!

Releases

hyper v1.0.0-rc.1

After so much work through this year, we finally published the first release candidate for hyper 1.0, hyper v1.0.0-rc.1!

The community had some wonderful things to say:

Parking in a stable stop is such a lovely metaphor for library evolution, love it!

Very exciting, this is a huge milestone for the maturity of Rust's web-facing ecosystem. :)

all aboard the hype(r) train! 🚂

As the announcement post said, we've got more to do. We're moving into the hyper polish period. I'll have more to say about that soon! But you can join us in chat now if you want to help out.

hyper v0.14.21

We also published v0.14.21, to bring some fixes and features to the more stable branch. This included advanced TCP Server options, an option to ignore invalid header lines, and some more bug fixes.

Part of the 1.0 plan is to backport as much as possible to 0.14, in an effort to make upgrading easier. So you'll still see 0.14.x releases along the way.

hyper 1.0

In order to publish the first release candidate, hyper v1.0.0-rc.1, there was a bunch of work to finish up.

@Michael-J-Ward created the per-version Connection types for the server module. And then I finished up the split by removing the combined hyper::server::conn::Connection type. @bossmc then removed an unneeded Option wrapping the internals of hyper::server::conn::http1::Connection, and dropped the try_into_parts method.

@LucioFranco refactored out the hyper::body::aggregate functions into a Collected type in http-body-util. I was able to use those to upgrade hyper with the new Body trait design that works on frames, making it forwards-compatible. I also finished up the bike-shaving to determine the name of the body type hyper returns, settling on hyper::body::Incoming.

hyper in curl

@dannasman cleaned up a feature we ended up not needing: the ability to get the raw response bytes. curl ended up preferring using the parsed response fields, keeping the parsing in Rust.

Are you interested in helping to debug the last few unit tests for hyper in curl?

HTTP/3

We're working on HTTP/3 in a separate crate, h3, with the goal of fitting it into hyper.

@g2p documented the entire public API for the h3 and h3-quinn crates. @eagr refined the compliance report generation, and exception reasons. In tower-h3, @eager made use of the new Body trait from the hyper rc1, and better use of Endpoint.

Tower

Tower (and tower-http) are a protocol-agnostic RPC framework with middleware, and they combine nicely with hyper.

@jplatte implemented Layer for tuples up to 16 elements, such that a tuple of layers is similar to using ServiceBuilder. @samvrlewis added methods to ReadyCache to allow iterating over the ready services, and implemented Clone fordiscover::Change. @boraarslan added a trait Budget, so that the retry middlware revamp can allow swappable budget implementations.