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

feat(server): re-design Server as higher-level API #1488

Merged
merged 1 commit into from Apr 16, 2018
Merged

Conversation

seanmonstar
Copy link
Member

The hyper::Server is now a proper higher-level API for running HTTP
servers. There is a related hyper::server::Builder type, to construct
a Server. All other types (Http, Serve, etc) were moved into the
"lower-level" hyper::server::conn module.

The Server is a Future representing a listening HTTP server. Options
needed to build one are set on the Builder.

As Server is just a Future, it no longer owns a thread-blocking
executor, and can thus be run next to other servers, clients, or
what-have-you.

Closes #1322
Closes #1263

BREAKING CHANGE: The Server is no longer created from Http::bind,
nor is it run. It is a Future that must be polled by an
Executor.

The hyper::server::Http type has move to
hyper::server::conn::Http.

Copy link
Member Author

@seanmonstar seanmonstar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently missing a replacement for run_until, but I'd expect to add a Server::graceful_shutdown method, and possibly a combinator that wraps Server with a select on another Future, so that a user doesn't need to do so manually...

.bind(&addr, new_service)
.unwrap();
let server = Server::bind(&addr)
.expect("bind to address")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm strongly considering making the default Server::bind either a) panic if binding errors, or b) lazily binding on the first poll of the Server. Forcing users to deal with an error that isn't likely to happen every single time feels like an annoying speed bump. Anyone wanting to handle a bind error can bind a TcpListener themselves, and use Builder::new.

}
#[deprecated(note="import from hyper::server::conn, or consider hyper::Server")]
#[doc(hidden)]
pub type Http = Http_;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm undecided on whether to keep this, or remove it. I did this since it allowed providing a hint in the message that things have changed, instead of simply hyper::server::Http is private. But it may be annoying to keep around for all of 0.12.x...

@seanmonstar seanmonstar force-pushed the server2 branch 4 times, most recently from 4fa759f to 67010fb Compare April 16, 2018 20:58
The `hyper::Server` is now a proper higher-level API for running HTTP
servers. There is a related `hyper::server::Builder` type, to construct
a `Server`. All other types (`Http`, `Serve`, etc) were moved into the
"lower-level" `hyper::server::conn` module.

The `Server` is a `Future` representing a listening HTTP server. Options
needed to build one are set on the `Builder`.

As `Server` is just a `Future`, it no longer owns a thread-blocking
executor, and can thus be run next to other servers, clients, or
what-have-you.

Closes #1322
Closes #1263

BREAKING CHANGE: The `Server` is no longer created from `Http::bind`,
  nor is it `run`. It is a `Future` that must be polled by an
  `Executor`.

  The `hyper::server::Http` type has move to
  `hyper::server::conn::Http`.
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

Successfully merging this pull request may close these issues.

None yet

1 participant