I am trying to build a hybrid HTTP + gRPC server using Axum and Tonic following this example. I am struggling a bit however on how to combine this with axum-server to have both over TLS:

let app = /* axum app */;
let grpc_service = tonic::transport::Server::builder().add_service(/* some gRPC service */).into_service();
let hybrid_make_service = hybrid(app.into_make_service(), grpc_service);

// This works fine
axum::Server::bind(&sc.bind_address).serve(hybrid_make_service).await?;

// This I can't get right...
axum_server::bind_rustls(sc.bind_address.to_string())
				.private_key_file(tls_key_path)
				.certificate_file(tls_cert_path)
				.serve(hybrid_make_service)
				.await?;

The issue seems to be that axum_server requires a 'Service' whereas the regular 'bind' accepts some sort of 'IntoService' (and the hybrid function, as well as grpc_service, create this). Any ideas?

When the SockAddr bind port is specified as 0, the kernel picks a random port to listen on. How does one gain access to this bound listener port? axum allows access to https://docs.rs/hyper/0.14.18/hyper/server/struct.Server.html#method.local_addr, how can one obtain the equivalent information using axum-server?

Hello,

I use rustls-acme to create automatically Let's Encrypt certificates like in https://github.com/FlorianUekermann/rustls-acme/blob/main/examples/low_level_axum.rs . It works very well, but the server seems not to respond with HTTP/2, even if the http2 feature is enabled in axum.

How can I enable HTTP/2 ?

Thanks and best regards.

I seem to be having trouble incorporating the example code into a toy project I am playing with to learn a bit of rust.

Not sure what he cause is, but I'm on 1.64 on fedora if that makes much of a difference

   Compiling axum-server v0.4.2
error: no rules expected the token `;`
  --> /home/fejfighter/.cargo/registry/src/github.com-1ecc6299db9ec823/axum-server-0.4.2/src/handle.rs:94:23
   |
94 |                 biased;
   |                       ^ no rules expected this token in macro call

error: no rules expected the token `;`
   --> /home/fejfighter/.cargo/registry/src/github.com-1ecc6299db9ec823/axum-server-0.4.2/src/server.rs:175:27
    |
175 |                     biased;
    |                           ^ no rules expected this token in macro call

error: no rules expected the token `;`
   --> /home/fejfighter/.cargo/registry/src/github.com-1ecc6299db9ec823/axum-server-0.4.2/src/server.rs:204:35
    |
204 | ...                   biased;
    |                             ^ no rules expected this token in macro call

error: no rules expected the token `;`
   --> /home/fejfighter/.cargo/registry/src/github.com-1ecc6299db9ec823/axum-server-0.4.2/src/server.rs:214:19
    |
214 |             biased;
    |                   ^ no rules expected this token in macro call

error: could not compile `axum-server` due to 4 previous errors

This takes a slightly different approach to what you suggested in #33, just wanted to get some quick feedback whether you think this would also be a good solution.

The main idea is to split up the builder from the actual server struct and bundle the server future together with the actually bound address.

Lately Axum has modified the internal implementation of Router and they have started boxing the routers by default (https://github.com/tokio-rs/axum). Unfortunately these new changes don't work with axum_server. I get following compilation error:

error[E0277]: `(dyn axum::clone_box_service::CloneService<axum::http::Request<axum::body::Body>, Response = axum::http::Response<http_body::combinators::box_body::UnsyncBoxBody<bytes::Bytes, axum::Error>>, Error = Infallible, Future = Pin<Box<(dyn futures_util::Future<Output = Result<axum::http::Response<http_body::combinators::box_body::UnsyncBoxBody<bytes::Bytes, axum::Error>>, Infallible>> + std::marker::Send + 'static)>>> + std::marker::Send + 'static)` cannot be shared between threads safely

I recently decided to port my application to the axum framework, and intend for my Rust binary to do its own SSL. This crate seems like the best way to achieve that (especially since it supports hot-swapping certificates :tada:). However, one of the issues I had with a previous web framework was severe, persistent TCP connection leaks, due in part to a lack of a timeout on accepting SSL connections (and also during http2 upgrade, but that's outside the scope of this crate). When I took a look at the source code, I couldn't help but notice that no timeouts or sleeps were incorporated into the relevant Futures. This leads me to believe that, were I to deploy my application in production, I would see TCP connection counts steadily climb as real clients have a habit of silently hanging up their connection at the worst time.

So my questions are:

1. Does this (or hyper, or axum) impose any timeout for SSL handshake? (or otherwise prevent this form of TCP connection leakage?)
2. If not, is there a workaround (such as implementing a custom acceptor)?
3. Would you prefer if I write a short test case to demonstrate an issue or lack there of?

hi, Eray, i've tested your recent posted rewrite-minimal redesign version, it works! but i noticed one problem: there is no way to make a single server to provide https and http dual protocol like version 0.2.5. This is a must-have feature, please please conside it.

I would like to wrap a user supplied app, like a Router, for that purpose I would like to use ServiceBuilder.

The issue is that Server::serve() needs a service factory, like what can be produced with Router::into_make_service(), which isn't available for ServiceBuilder.

The solution I found is wrapping it in Shared. I believe some documentation in axum-server would help.

See https://github.com/tokio-rs/axum/issues/1203 for the original problem.

Hi,

When using Axum with WebSockets, I noticed having an open WebSocket doesn't stop the server from shutting down gracefully. Here's a demo repository.

My expectation was that the demo would remain running for 30 seconds, printing "beep" every second until the graceful shutdown timeout is reached.

I'm not terribly familiar with Hyper so I don't immediately see a fix, so I figured I'd start with an issue. I'm happy to work on a fix, however.

from_pem_file() calls eventually to config_from_pem() which restricts the keys to be of type Some(Item::RSAKey(key)) or Some(Item::PKCS8Key(key)) and this rejects a lot of EC keys. One either needs to convert it from SEC1 to PKCS8 or directly encode into DER and load the files by hand to call from_der() instead.

Adding proper support for EC keys should be as simple as adding Some(Item::ECKey(key)) to the match clause of config_from_pem(). I'd be happy to open a pull request for it.

I really do like the easy of working with axum and axum-server. It is straightforward to set up TLS and reload it, which is awesome when used with certificates that need to renewed often.

I would be genuinely interested in binding a server to multiple sockets of different types. For example, to accept an arbitrary list of TCP and unix domain sockets via systemd socket activation:

	let tls_config = RustlsConfig::from_pem_file(
		"examples/self-signed-certs/cert.pem",
		"examples/self-signed-certs/key.pem",
	)
	.await?;

	let server = axum_server::new();

	let mut lfd = ListenFd::from_env();
	if lfd.len() > 0 {
		for idx in 0..lfd.len() {
			if let Ok(Some(lst)) = lfd.take_tcp_listener(idx) {
				server = server.from_tcp_rustls(lst, tls_config);
			} else if let Ok(Some(lst)) = lfd.take_unix_listener(idx) {
				server = server.from_uds(lst);
			} else {
				warn!("Unsupported socket type at index {:?}", idx)
			}
		}
	} else {
		server = server.bind("[::]:3000".parse()?)
	}

	let app = Router::new().route("/", get(|| async { "Hello World" }));
	server.serve(app.into_make_service()).await?;

Having the same app listening on multiple sockets greatly improves usability and integration with many systems, such as systemd. Unix domain sockets are often used to provide a service to other local services, such as reverse proxies or load balancers. A second TCP listener is often spawned e.g. for debugging or monitoring purposes.

Does this feature sound reasonable for axum-server?

I wrote an Acceptor that allows handling of HTTP and HTTPS on the same port. The implementation is fairly minimal and simple. Is it in scope for axum-server to add something like this? Happy to start a PR of course.

My use-case is hosting a HTTPS server on a custom port, unlike the example, there is only one port. So connecting with HTTP to that server errors out. The idea is if I accept both protocols, I can design a middleware that handles the redirect.

An util module with optional util feature can be created to provide higher level features.

Some possible high level features:

• Recording bytes for each connection. This can be useful to log client data usage.
• Binding to multiple addresses on a single struct.
• Http and https server on a single struct.

Currently there is no way to shut a connection down except signaling a global shutdown.

Having this ability can be useful to detect slow clients and prevent some attacks.