When you want to implement a HTTP server using aiohttp you currently have two choices:

• buy into the full stack. This lets you use the request and response object, and includes the application object and the router.
• buy into the ServerHttpProtocol. This is very low-level.

I'm interested in the equivalent of webob: have a request a response object, but no assumptions about routing or the way applications get constructed. So something built on top of ServerHttpProtocol that lets you use the request and response objects but no other assumptions made. This would:

• make my current task easier: I'm trying to write a HTTP proxy using aiohttp's client and server facilities. A proxy doesn't need the router, but it is helped by the request object.
• would make it easier for web frameworks to be built on top of aiohttp that are an alternative to the one it ships with.

I've been trying to engage with the low-level ServerHttpProtocol layer to see how far I can get. I ran into the following difficulties:

• the new test_util.TestClient expects an app object. I hacked around this by making a subclass that takes a handler instead, but it would be nicer if this class existed in the framework.
• in order to figure out the http scheme I want the equivalent to request.scheme. I ended up initializing a Request object manually and passing None as the first argument, as this is supposed to be an app instance. I noticed that the server Request depends on app but very minimally so, but it still expects the app as the first argument. I'm looking for a request object that doesn't depend on the app at all.
• I'm now trying to figure out how to run a low-level handler with gunicorn, but the documentation only discusses the app level so I'm currently lost.

My impression from the documentation and the code is that this "middle layer" is not really a priority of the framework. People are pointed to the higher level application object. The test client doesn't support the use case either. aiohttp tantalizingly close to supporting this use case, but it isn't quite there.

So my question the developers is this one: is this something you're interested in supporting with aiohttp at all, or is this just not interesting to you? Would you accept contributions that moved aiohttp into this direction?