I don't think I have any criticism for your approach on your project. I was trying to comment on the idea that WSGI somehow conflates buffered mode with stream

I don't think I have any criticism for your approach on your project. I was trying to comment on the idea that WSGI somehow conflates buffered mode with streaming mode. How is that even possible when WSGI does not even have a notion of buffered mode? If you want your app or even your framework to buffer, you can just do that in the app layer. I can't see that the server interface should have additional moving parts just to do what is cleanly doable in the app layer. I can only imagine this being a disappointment if someone wanted to use WSGI middleware to carry out buffering. But if (edit: internal) WSGI compatibility is not a high priority, then why would you want to use WSGI middleware for this (generally pretty messy)? Do it in your framework or in your app. So I do not understand the complaint about the 'conflation' of buffering and streaming. I think it is appropriate to leave the buffering decision in the app layer. And it is also reasonable to use WSGI as just a way to talk to a server (what else is it really for? Obviously not to offer a big fat servlet API...) If you want to do separate buffering and streaming APIs in your app layer then that could be a smart way to reduce complexity but I don't see why this is some sort of complaint about WSGI.