On Fri, Dec 19, 2025 at 01:10:16PM +0100, Hank Bowen wrote: > > The common issue with > > keep-alive (and most annoying case) is servers responding that they do > > intend to keep the connection alive and immediately close after the > > response. If they do it in the same packet we get the info, if they > > don't, we get this info late, often after having sent a new request > > there. But indeed, servers will generally close much faster after a > > first request than before since it's unsure whether the client wants > > to reuse that connection. > > I'm not sure if I properly understand the last sentence. That is, it should > be understood: "during the first request the issue of reusing connection is > of no matter at all because it was not even completely used yet, so the > possible timeout will be typically high; but when it comes to subsequent > requests the server cannot be sure if a client having received a complete > responses to all the requests it initiated on this TCP connection will want > to send yet another request on it, so the timeout will typically be low (in > order to prevent server resources being taken unnecessarily)"?
Exactly! > > In these multiplexed protocols, there can be more than one request in > > flight over a connection, they come in any order. So the principle > > remains (and can be generalized to) : "when all requests have been sent > > entirely and got their entire response, the connection is idle". For > > HTTP/1, it's one req/resp at a time. For H2/H3/FCGI, it can be many at > > a time. > > OK but the quoted fragment suggests that it is possible to have a single TCP > haproxy <-> server connection with streams (in case of HTTP/2 - HTTP/2 > streams as I understand) of different sessions (although it would require at > least "aggressive" mode of http-reuse). But having considered that the > connection is recognized idle only after all requests have been sent and got > their entire responses, I cannot see any possibility for that. It's just that the principle of whether to reuse a connection or not remains tied to the session itself: in safe mode, the first request of a session will be delivered to its own fresh new connection, thus it will not be mixed over an existing backend H2 connection. > That is, let us assume that on a given TCP haproxy <-> server connection one > stream is being processed and http-reuse is in "aggressive" or "always" > mode, so the mentioned TCP connection is not (per documentation) reserved to > handle streams of the same sessions. Another client comes in with a request > and as I understand the fact mentioned after last comma is a necessary > condition for that request being allowed to be directed to that TCP > connection. But... there is a stream being processed there, so request - > response are not fully exchanged, so the stream cannot be considered idle, > so that is anyway impossible. So effectively any TCP connection is anyway > reserved to handle streams of the same session. Is there some flaw in my > reasoning? I'm having a difficulty understanding the case you're trying to explain. An H2 connection on the backend is multiplexed, so it sees multiple concurrent streams, possibly from multiple front connections/sessions. The notion of idle here is much less relevant (it still happens that the connection becomes idle when no more request is active on it). But generally speaking, since there's no need to wait for the end of a response to send a new request, you just pick a connection with some available streams and send your request on it. > Perhaps it'll be of some help here if I say that I have a pretty good > understanding of HTTP/2 protocol (I do understand that requests and > responses are broken into frames and frames of different requests can be > sent interleaved on the same TCP connection and the same holds true for > different responses). OK, so I don't know if what I mentioned above clarified a bit the situation for you :-) Willy
