Envoy: No way to configure an idle timeout for unused downstream http connections?

[jcdavis]

Title: No way to configure an idle timeout for unused downstream http connections?

Description:
I've been looking into a way to specify a maximum time for an unused connection to live in the pool before being closed. I was/am hoping for something similar to nginx's keepalive_timeout, which creates a timer on the connection after finishing the http response.

Am I correct in understanding that there is currently no way to do this? The idle_timeout parameter for the connection manager seems to be a timeout on idleness during an http request - it is reset on receiving headers/body. I've looked through the http1 pool implementation as well as the somewhat similar to #8302 and can't seem to find this behavior.
(Apologies for the the vague phrasing here - I'm still not 100% sure that envoy does not in fact support this behavior somehow)

[zuercher]

Envoy has two concepts related to this in the http connection manager:

common_http_protocol_options.idle_timeout (which supersedes idle_timeout) will close a connection when no request has been active for the given interval. For http/1.1 you can think of this as measuring the time since the last response to the downstream client was completed.

stream_idle_timeout will close a connection if no activity has occurred on the downstream connection (send or receive) for a given interval (e.g. a network stall mid-request, mid-response, or a very slow response from an upstream).

[jcdavis]

Thanks for the explanation! Like I said, I might've been confusing the two. Though I am curious why the connection_idle_timer_ is setup in ConnectionManagerImpl::initializeReadFilterCallbacks

[zuercher]

I believe initializeReadFilterCallbacks is invoked as soon as the connection is formed and the network filter chain (e.g. the http connection manager) has been instantiated. When the client sends a request, ConnectionManagerImpl::newStream is called and the timer is disabled. Normally that enable/disable sequence happens almost immediately, but a client that connects and never sends a request will be subject to the idle timeout.

The stream_idle_timeout applies to active streams, so my previous comment is not entirely accurate -- it should refer to streams which have a different meaning in http/2 vs http/1.1. You could get a stream idle timeout in h2 if one of multiple concurrent requests stalls.

[jcdavis]

Great, appreciate the detail - clears things up a bit