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:
- Is closing the connection really an error? If no, it should not bubble up and be reported as such.
- Where is this coming from? I suspect from hyper_rustls, since the non rustls hyper server does not have the same behavior.
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:
Example requests:
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):
This is obviously coming from this part of the code:
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: