-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
I'd be very interested in hearing about your issues here. Also, have you used the |
@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! |
@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? |
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. |
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. |
You're right! Clearly misread on my part. |
@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? |
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. |
BTW: Hyper just merged the tokio branch: hyperium/hyper@2d2d557 |
@thedrow Hyper plans on doing HTTP2 support before hitting 1.0 |
@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. |
@JonasZ95 I certainly didn't say that. |
FYI: hyper |
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. |
@beatgammit Maybe look at Right now Rocket handlers can return anything implementing #[get("/")]
// is this the proper syntax?
fn hello() -> impl Future<String, io::Error> {
future::ok(String::from("hello"))
} |
Futures Await now work on nightly: https://github.com/alexcrichton/futures-await |
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. |
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? How complex would it be to implement an initial support for futures-backed Rocket? |
@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:
|
@mersinvald
|
I have a tiny adapter that transforms any sync code into a |
|
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.
Right. As I said, I'm not a web dev, so I've no idea why a web framework should care about database access.
Sure, with a thread pool you get that. With |
Litigating the useful-ness of asynchronous programming is extremely off-topic for this issue, IMHO. Could we maybe not do this here? |
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. |
A port to Hyper 0.12 seems to be in progress here: #1008 in case anyone else is interested. |
@jebrosen @schrieveslaach thoughts on taking this Hyper upgrade effort/opportunity and go all the way up to Hyper 0.13 instead? Which supports 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! |
@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. |
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 |
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 |
genuine question, what indicates that it will be a near future? My limited understanding is that the path to hyper@0.13 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 |
I would expect But I'm not affiliated with the projects, so I may be wrong. |
tokio 0.1 and futures 0.1 are intentionally excluded from the public API in my 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. |
If anyone wants to read about hyper v0.13: https://seanmonstar.com/post/189594157852/hyper-v013 |
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. |
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:
Date
header.Header
names and values.The text was updated successfully, but these errors were encountered: