Error after serving HTTP request over TLS

[casey]

Thanks for rustls-acme! We're using it to automatically fetch TLS certs for a daemon, and it's working great.

We're using the low-level interface, because we're using tokio, so we're configuring ResolvesServerCertUsingAcme but otherwise doing everything ourselves.

You can see our code here.

Fetching certs and serving connections is working perfectly, but the result of Http::new().serve_connection(tls_stream, request_handler).await is returning an error.

You can see the log::error! that's firing here.

The specific error message is:

[2021-10-20T22:22:10Z ERROR agora::https_request_handler] Error closing TLS connection: connection error: not connected

This isn't causing any problems for us, although we'd like to be able to stop ignoring this error, in case it masks more serious errors in the future, so we wanted to ask if you've seen this error before, or if you had any ideas as to what might be the problem.

Our TLS knowledge is pretty fuzzy, and it seems likely that this actually isn't a rustls-acme issue, but maybe an issue with our code, or with a lower-level crate, like rustls or hyper, but we thought we'd start with an issue here.

[FlorianUekermann]

I had a quick look at your code and the way you use the acceptor looks fine at first glance. I couldn't find your actual handler code. The error sounds like either the remote peer or server closed the connection and then you still do stuff on it.

If you explicitly close the connection somewhere to clean up, maybe want to ignore the result.

This is interesting timing, because I just released 0.2.0, which removes the option from the return value of accept and hands you closed tls connections when it handled a let's encrypt connection. So I doubt that this error currently originates from rustls-acme, but in the future you will see errors like that during certificate refreshes (so very rarely).

If you point me to the actual handler code that is called after you get a tls connection, I can take another look if I see something obvious.

[casey]

I had a quick look at your code and the way you use the acceptor looks fine at first glance.

Thanks for taking a look!

The error sounds like either the remote peer or server closed the connection and then you still do stuff on it.

That seems reasonable, we thought of rustls-acme since we don't seem to be getting this error otherwise. However, we're not calling our handler the same way here, so it could easily be something else we're doing that's weird.

If you point me to the actual handler code that is called after you get a tls connection, I can take another look if I see something obvious.

Our request handler's service implementation is here. Let us know if it looks weird, and otherwise we'll look elsewhere in the stack.

Thanks for the help!

[FlorianUekermann]

I had a look and didn't notice anything. rustls-acme is just doing the certificate related bits. The rest is handled by async-rustls. And even that is just transport for http in your case, so it would be surprising if any of that stuff closed a connection.
I'm closing here, feel free to repoen if you get some indication that rustls-acme or any of its dependencies are the culprit.

Two more notes:

1. If I had to guess, this may be a persistent http related issue, where the server tries to read the next http request from the connection, but the connection was already closed, which is perfectly fine behavior (the client may close when it isn't interested in sending more request).
2. Try to figure out where the error originate, that should make it more obvious what is going on.

[casey]

That all sounds right to me. I think you're right that the most likely answer is related to persistent HTTP. I think what made me not think of that initially was just the expectation that hyper would somehow handle that automatically.

Thanks for following up!