This is great stuff. Defining a clear API layer between server implementation and framework has been something we are already doing with Hummingbird. But to be able to do this across the whole eco-system opens a whole load of additional possibilities.
Have you considered making the HTTPRequestContext generic as well. I currently don’t see anyway to pass server implementation details to the framework layer. For instance a framework might want the remote IP address to perform rate limiting. With the current protocol design I don’t see how this could be achieved. You could just add these values to HTTPRequestContext but there might be other values, as yet undefined, that server implementations want to pass. I guess you could do this with Task locals but isn’t it preferable we test for the existence of any additional context information at compile time over run time.
I’m not a great fan of some of the symbols and find them quite a mouthful egHTTPRequestConcludingAsyncReader. But I don’t have any sensible alternatives.
The NIO server implementation is dependent on both NIOSSL, NIOHTTP2 and related libraries. Hummingbird has always tried to only include the dependencies required eg a vanilla HTTP/1.1 server wouldn’t required compiling and linking TLS, HTTP2 code. If we were to move to the NIO default implementation we would lose that. Would using traits to enable/disable elements of the server implementation be something you would consider looking into?
In whole though this is great move forward.