Stabilize HTTP library

[SergioBenitez]

At present, Rocket reexports Hyper types under http:hyper. Hyper causes a lot of issues, particularly when trying to optimize performance. A decision needs to be made on whether to stabilize these Hyper types, move away from Hyper (likely), or do something else all-together.

If we do move away from Hyper, here are things we should see to it that we re-implement or ensure the new library provides:

• Automatic injection of the Date header.
• Validation of outgoing Header names and values.

[steveklabnik]

I'd be very interested in hearing about your issues here. Also, have you used the tokio branch at all?

[aturon]

@SergioBenitez The Tokio team is working toward a 0.1 release of the Tokio stack, after which HTTP is likely to be more of a focus. We should try to work together in exploring the space. Let's be in touch!

[yazaddaruvala]

@SergioBenitez if the plan is to move to an async back end, why does the current API not use Futures? Or is the plan to change the API to a Futures based interface before 1.0? Or do you plan to keep the sync API interface but have an async backend?

[blaenk]

I'm also curious about what @yazaddaruvala said. It would seem to me that Futures would be returned as a a way of future-proofing for async. Then again, maybe it's possible to accommodate handlers that return Futures and those that don't? Perhaps even using codegen/procedural macros.

I ask in light of tokio reaching 1.0, hopefully increasing the pace at which async infrastructure is developed.

[SergioBenitez]

Tokio has reached version 0.1, not 1.0!

@yazaddaruvala To directly answer your question, there's no point to having the Rocket API know about any kind of asynchronous I/O as Rocket doesn't perform async. I/O. Having some notions of async. I/O that don't, in reality, perform the I/O asynchronously would be rather confusing.

I don't have a design I'm willing to commit to at this point. The Rust asynchronous I/O space is in heavy flux. The Tokio 0.1 release today is a milestone in reaching stability, but there's still a long road ahead. Rocket will be fully asynchronous in the future, but the approach must be made with care. Usability is of utmost importance, and performing and handling async. I/O with Rocket cannot be an exception.

[blaenk]

You're right! Clearly misread on my part.

[yazaddaruvala]

@SergioBenitez I can appreciate that it might be too early to make implementation decisions. However, its not clear from your comment or the rest of this thread, and I'm curious about your vision.

Does sync IO, fit with your current vision of what Rocket will be? Asked a different way: Is there a possibility that, a future 1.0 release of Rocket could use synchronous IO or can you guarantee that the 1.0 release of Rocket (whenever that comes out) will be based on some implementation of async IO?

[SergioBenitez]

As I said in my previous comment: Rocket will be fully asynchronous in the future. This issue will not be resolved until the HTTP server backend is stabilized, and this issue is currently set to be resolved before 1.0. I consider asynchronous I/O to be a requirement for stability.

[flosse]

BTW: Hyper just merged the tokio branch: hyperium/hyper@2d2d557

[mgattozzi]

@thedrow Hyper plans on doing HTTP2 support before hitting 1.0
hyperium/hyper#304

[jon-zu]

@SergioBenitez Do I get this right, you don't have any plans to add futures as return values for handlers?

If so I think that icould be troublesome, because you may query a database in a handler which results mostly in IO. Returning a future would allow nice chaining.

[SergioBenitez]

@JonasZ95 I certainly didn't say that.

[webbrandon]

hyperium/hyper#304 (comment)

[flosse]

FYI: hyper v0.11 just released :)

[beatgammit]

Is this currently a development priority? If so, is someone working on it? I don't see a branch for this, so my guess is no.

I may be interested in helping port to hyper 0.11 (async), but I'm a bit unclear with the Rocket codebase (just started using it for a project) so I don't feel like I have a good intuition as to what a good API would look like.

[lnicola]

@beatgammit Maybe look at tokio-minihttp.

Right now Rocket handlers can return anything implementing Responder. As a straw man user-facing API, we might want to allow handlers that look like:

#[get("/")]
// is this the proper syntax?
fn hello() -> impl Future<String, io::Error> {
    future::ok(String::from("hello"))
}

[lilianmoraru]

Futures Await now work on nightly: https://github.com/alexcrichton/futures-await

[harryfei]

Repost the question #559 here.

Does anyone have experience with actix-web. It seems that it support HTTP, HTTP2, async concurrency and websocket which are needed to implement a morden web server.
Currently the Rocket use hyper as then web backend which limits HTTP2 and websocekt features. Shall we use actix-web to replace hyper to get all those features?
If we decide not to change our backend, shall we split our rocket sugar syntax code into a separate project, so that we can reuse it's code to add the nice syntax for other web framework?

[mersinvald]

Rocket looks so nice, but its synchronous nature is still a showstopper for services requiring to access external APIs while handling requests.

Any progress on bringing async into rocket like an optional feature for writing handlers?
Maybe something like a custom Responder with a futures-cpupool as a back-end threadpool?
This would allow using async and sync API at the same time, as far as I understand.

How complex would it be to implement an initial support for futures-backed Rocket?
I could dive into it, but I definitely would like to hear a team vision on the topic.

[mgattozzi]

@mersinvald it would require updating hyper to 0.11 at the least in order to have async. However with the tokio reform moving to 0.2 soon and hyper 0.12 to follow not long afterwards it might be some time. Really though @SergioBenitez already said why he hasn't moved to async above early on in the thread:

I don't have a design I'm willing to commit to at this point. The Rust asynchronous I/O space is in heavy flux. The Tokio 0.1 release today is a milestone in reaching stability, but there's still a long road ahead. Rocket will be fully asynchronous in the future, but the approach must be made with care. Usability is of utmost importance, and performing and handling async. I/O with Rocket cannot be an exception.

[steffengy]

@mersinvald
I experimented with something like that previously in 2 stages in this branch:

• using synchronous handlers backed by futures-cpupool & hyper down to async connections
  ergonomically the same as currently but not really beneficial since you cannot use async handlers
• introducing asynchronous handlers
  required enormous BC breaking changes and ergonomically much worse to use than synchronous handlers (This was before futures-await).

[lnicola]

I'd really like to write my service in Rust, but currently all franeworks are waiting for async stuff to happen and ready up for a complete rewrite.

tower-web and warp are async-first and are already usable, depending on what you expect from a web framework. I'm not a web dev, so I was fine with e.g. implementing sessions from scratch.

Tried actix-web and pushing database stuff into different threads and managing messages is far from easy convenient.

I have a tiny adapter that transforms any sync code into a Future that works with the blocking support in tokio. It's not that much of an inconvenience. Alternatively, any thread pool could do the same thing.

[geromueller]

• They both are lacking database examples, for a good reason ;-)
• I read about that blocking feature in the diesel discussion as well. I did not find any example and how it is supported by the frameworks. You need some control over the amount / spawning of threads after all.

[lnicola]

They both are lacking database examples, for a good reason ;-)

Maybe try making an example app and publishing it somewhere? I guarantee it's possible. If you start something and run into issues, you can ping me.

I did not find any example and how it is supported by the frameworks.

Right. As I said, I'm not a web dev, so I've no idea why a web framework should care about database access.

You need some control over the amount / spawning of threads after all.

Sure, with a thread pool you get that. With blocking, there's a (pretty large) number of threads that are made available by the runtime.

[steveklabnik]

Litigating the useful-ness of asynchronous programming is extremely off-topic for this issue, IMHO. Could we maybe not do this here?

[geromueller]

To summarize my concern: You can not just switch from sync to async without big changes in the user code. And for a new project API stability is an issue.
Edit: see here for problems popping up when you go async nodejs/node-v0.x-archive#7543

[nicoburns]

A port to Hyper 0.12 seems to be in progress here: #1008 in case anyone else is interested.

[viniciusd]

@jebrosen @schrieveslaach thoughts on taking this Hyper upgrade effort/opportunity and go all the way up to Hyper 0.13 instead? Which supports async/await syntax.
Hyper is currently mostly ported towards std::future and async/await. I am pointing that because moving from 0.12 to 0.13 in the future would require another big refactor out of the .and_then().map().map_err() world.

I acknowledge that is mostly covered by @jebrosen's last comment on #1008

I know I am saying that as an outsider and both of you have put a lot of efforts and work into making this upgrade possible. Huge congrats on that btw!

[schrieveslaach]

@viniciusd, I checked crates.io for Hyper 0.13 but I could not find the next minor release. Do you know that the next minor version is coming soon? If so and if @jebrosen agrees on it, I could try to upgrade his async branch to Hyper 0.13.

[apiraino]

For the benefit of those following this issue, let's keep in mind that Hyper 0.13 will be far from being a minor release without breaking changes, this is the tracking issue.

They're moving from [email protected] to stable std::future::Future (released just one month ago). As much as I'd like Rocket to be async, I wouldn't stay too close to their bleeding edge.

[viniciusd]

As @apiraino pointed out, 0.13 hasn't yet been released. Hyper's master branch is going to be tagged as 0.13 at some point in the near future.

I would say we are already going for a breaking change moving from 0.10 to 0.12. Upgrading to 0.13 afterward would take just as much efforts if it isn't done at once

[apiraino]

Hyper's master branch is going to be tagged as 0.13 at some point in the near future

genuine question, what indicates that it will be a near future? My limited understanding is that the path to [email protected] doesn't look straight, they're actively working on it.

My comment was more along the line of "I wouldnt hold my breath to have [email protected] soon, therefore I wouldnt push Rocket to rely on hyper@master. Happy to hear a more informed opinion!

[lnicola]

I would expect hyper and tokio to get released after await hits stable, if not a bit earlier (as pre-release versions).

But I'm not affiliated with the projects, so I may be wrong.

[jebrosen]

tokio 0.1 and futures 0.1 are intentionally excluded from the public API in my async branch by using the 0.1/0.3 compat layer in a few strategic places. Therefore, moving from hyper 0.12 to 0.13 is not much of a code change and it should only affect internal functions and maybe a few public header re-exports, unlike 0.10 to 0.12 which requires most of Rocket's public API to become async-aware. I would like that transition to happen before any betas or RCs for rocket 0.5, but the master branches of hyper and tokio are not quite ready yet the last time I tried.

I will be elaborating more on these and other async-related progress and problems in a tracking issue in the next several days if nothing critical comes up.

[ghost]

If anyone wants to read about hyper v0.13: https://seanmonstar.com/post/189594157852/hyper-v013

[SergioBenitez]

Rocket 0.5 now exposes almost none of hyper, which means we don't need to consider the underlying HTTP library as a breaking dependency and can close this issue. We should, however, seek to implement now-missing functionality, such as #1067.