v0.26 server example error: failed to serve connection: error shutting down connection

[Vagelis-Prokopiou]

Hello all. Thank you for all your hard work.

System:
Linux debian 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux

I am testing out the latest version server example before updating my application.
The "problem" is that for every request I get this in the console output:

failed to serve connection: error shutting down connection

Example requests:

curl -v -k https://127.0.0.1:1337
curl -v -k -d 'hello=world' https://127.0.0.1:1337/echo

Keep in mind that this behavior only happens with the curl requests. Not with the browser requests.

The only difference to the example is that I only enable HTTP 1/1 (but I don't think that this is related at all):

server_config.alpn_protocols = vec![b"http/1.1".to_vec()];

This is obviously coming from this part of the code:

if let Err(err) = Builder::new(TokioExecutor::new())
.serve_connection(TokioIo::new(tls_stream), service)
.await
{
    eprintln!("failed to serve connection: {err:#}");
}

All the requests are fulfilled ok (Status 200), so this error is kind of misleading. Should the closing of the connection be an error in itself?

I tried to debug it a little bit. to identify what exactly is going on, but I did not get to far. I noticed though that the non TLS hyper (v1) server does not produce this error (see latest https://github.com/hyperium/hyper/blob/master/examples/echo.rs).

So, to sum up:

1. Is closing the connection really an error? If no, it should not bubble up and be reported as such.
2. Where is this coming from? I suspect from hyper_rustls, since the non rustls hyper server does not have the same behavior.

[Gelbpunkt]

I was running into this while testing #232 and decided not to look further into it because I was able to reproduce it on 0.25 as well. It seems to be a curl-specific bug, see this comment on the hyper issue related to the bug.

[cpu]

I think our position is still the one echoed in the linked comment and should be something addressed in Hyper. I'm going to close this issue for now but if the situation changes or someone disagrees we can revisit.