That seems mostly like the question of "Does this HTTP framework support HTTP pipelining". While I don't know the answer, it doesn't seem highly relevant. Most clients went away from using pipelining, since follow-up requests on the same connection are subject to unknown latency (stuck behind the first request) and a connection failure can impact all of those requests.

The better approach is to use either more connections, or proper request multiplexing via HTTP/2 or /3. In the latter case a server framework would just see multiple request invocations in parallel.

No, that's a different thing. HTTP request 2 from this scenario is from an entirely different client on an entirely different socket connection.

(This kind of architecture might also be useful for http pipelining, but that's not the question in this scenario)

> subject to unknown latency (stuck behind the first request)

Also known as "head of line blocking" https://en.wikipedia.org/wiki/Head-of-line_blocking

Yes, this is possible!

In fact this is a perfect use case for Falcon + Async.

I just tried this out. Falcon with count=1 & sinatra. Worked perfectly. It seems every request is processed in an async block so literally no special code is required. A request waiting on network will allow others to go through.

This is awesome! :)

It does, and that’s specifically why I’m really looking forward to benchmarks for rack frameworks switching to falcon - while it may not take Rails to Phoenix’s performance and latency, I bet it would close the gap considerably.