cloudflare
Fixes broken Keep-alive: Persist `keepalive_timeout` between requests on same stream
See #540 See #447
Basically, for HTTP/1.x, the current implementation of the "keep alive" logic is broken and does not function as intended. Although it is possible to modify the "keep alive" value during the HTTP request lifecycle, if the existing stream is kept open and re-used, the request loop creates a fresh HttpSession, with no information from the prior HTTP request, and reverts back to using an infinite-time keepalive. This results in issues if the client never disconnects (and waits for the server to disconnect), resulting in the problems outlined in #447, #540, etc.
This PR attempts to solve this issue by finding the minimal changes required so that the stream re-use event loop has some state information from the previous request. It does this by introducing the concept of ProcessResult, which wraps the existing Option<Stream> that the existing HTTP lifecycle already had, but then provides a mechanism to then "persist" some HTTP session settings via PersistentSettings
In this PR, the only thing being persisted is the session's keepalive_timeout, however, I do believe it would also make sense to also persist read_timeout and write_timeout, as these too also get reset after each request over the same connection/stream.
I can continue to work on this to add in support for read_timeout and write_timeout, but wanted to first run this current approach by the Pingora team for some feedback, before I spend too much time going with an approach that would not be accepted. I went with the approach of solving for the multi-request-same-stream state persistence within HttpServerApp, since the outer request loop engine ServerApp does not provide a method for multi-request state, and didn't want to introduce the concept at that higher level if the only thing that cares is HTTP servers doing HTTP/1.x.
@drcaramelsyrup @gumpt @Noah-Kennedy wanted to follow up on this PR, as I believe the issue still exists (Keep-Alive does not function as intended)
@drcaramelsyrup thanks for such a detailed writeup. I'm completely fine with you taking the ball from here and going with the approach you've been working on. Since your approach is a bit more involved and modifies some of the core architecture of handling HTTP requests, I think that it makes sense for you / your team to finish the implementation.
Thanks, this was merged in 6f44ac78ef7b3a036af57804537c67c7f2fea364, with the suggested revisions on top in fa466f64bdbf4715cf34b93192ee3c5d33628361.
