zarqman

@grzuy, appreciate the quick response. As added background, part of our auth process dynamically affects Rack::Attack's rate limits. Because of that tight relationship, we use the following to assure everything...

@fatkodima, there are a few reasons we'd rather not have duplicate copies of Rack::Attack in the middleware stack: - It adds confusion to any developer who looks at the stack...

@grzuy Correct, no other changes in 6.2 have broken anything else.

@jarthod We found a way around this. It's super hacky, and a directly supported path with an alternate `require` would still be preferred, but it is working for us. ```ruby...

+1 Would really like to see one of the PRs that addresses failover pulled soon.

@jperichon, we've been using it successfully in production for 3+ months. We added a couple of patches on top of it to fix up things it missed. Haven't seen any...

@ioquatix, I added graceful stop to our `async-http` powered app here and thought I'd share a couple notes on the current design in case it helps. To handle keep-alive and...

> In addition, the HTTP/1 connection request/response loop will terminate after the response is finished sending. This needs to happen, but the `defer_stop` model cannot do this alone. The HTTP1...

As requested, I've created a pair of PRs (socketry/async-http#130 and socketry/protocol-http1#21) to explore this. It's just a spike and is not complete. I'm hopeful it will further the discussion. In...

On the http1 side, I've just submitted socketry/protocol-http1#23 which simply breaks out reading of the initial request and response lines, as contemplated above. This makes it easier to precisely target...