Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize HTTP library #17

Closed
SergioBenitez opened this issue Oct 1, 2016 · 68 comments
Closed

Stabilize HTTP library #17

SergioBenitez opened this issue Oct 1, 2016 · 68 comments
Milestone

Comments

@SergioBenitez
Copy link
Member

SergioBenitez commented Oct 1, 2016

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.
@SergioBenitez SergioBenitez added this to the 1.0 milestone Oct 4, 2016
@steveklabnik
Copy link

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

@aturon
Copy link

aturon commented Dec 23, 2016

@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
Copy link

@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
Copy link

blaenk commented Jan 11, 2017

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
Copy link
Member Author

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
Copy link

blaenk commented Jan 11, 2017

You're right! Clearly misread on my part.

@yazaddaruvala
Copy link

@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
Copy link
Member Author

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
Copy link

flosse commented Jan 18, 2017

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

@mgattozzi
Copy link

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

@jon-zu
Copy link

jon-zu commented Feb 22, 2017

@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
Copy link
Member Author

@JonasZ95 I certainly didn't say that.

@webbrandon
Copy link

@flosse
Copy link

flosse commented Jun 13, 2017

FYI: hyper v0.11 just released :)

@beatgammit
Copy link

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
Copy link
Contributor

lnicola commented Jul 25, 2017

@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
Copy link

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

@harryfei
Copy link

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
Copy link

mersinvald commented Feb 14, 2018

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
Copy link

@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
Copy link

@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
Copy link
Contributor

lnicola commented Oct 15, 2018

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
Copy link

  • 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
Copy link
Contributor

lnicola commented Oct 15, 2018

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
Copy link

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

@geromueller
Copy link

geromueller commented Oct 15, 2018

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
Copy link

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

@viniciusd
Copy link

viniciusd commented Jul 28, 2019

@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
Copy link
Contributor

@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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

lnicola commented Jul 29, 2019

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
Copy link
Collaborator

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
Copy link

ghost commented Jan 21, 2020

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

@SergioBenitez
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests