If it's not working out because wsgi.input can't be read twice, then write a middleware that turns it into a StringIO, and write another middleware that rewinds it.
Nothing is going to save you from the fact that you either need to buffer your response, or don't throw an unhandled exception after it's started. Yes it's a problem, but buffering is the only magic that'll help.
If the problem is that middleware authors can't be bothered to implement the whole spec because it's too hard, then submit a patch. I promise you that WSGI is easier to implement than HTTP/1.1 In fact, I would argue that it's as easy as possible. If it were easier, we probably wouldn't be having this discussion, because it wouldn't have been powerful enough to have been adopted.
Or write a middleware container that transforms the WSGI api into something you think is more sane, then implement middleware in thate.
Build the next great thing on top of WSGI, because in the end, the answer is either WSGI, something that's architecturally equivalent, or else each framework has to have its own compression, session, and other libraries. And no answer is going to save you from having to do a little bit of work to put things put together correctly.
I just don't understand why we need a single monolithic product that is at the core of the system. When you use any language specific API you are locking out possibly useful tools.
The overhead of asking each component to use HTTP is an acceptable price to pay for native compatibility with the Internet.
Nothing is going to save you from the fact that you either need to buffer your response, or don't throw an unhandled exception after it's started. Yes it's a problem, but buffering is the only magic that'll help.
If the problem is that middleware authors can't be bothered to implement the whole spec because it's too hard, then submit a patch. I promise you that WSGI is easier to implement than HTTP/1.1 In fact, I would argue that it's as easy as possible. If it were easier, we probably wouldn't be having this discussion, because it wouldn't have been powerful enough to have been adopted.
Or write a middleware container that transforms the WSGI api into something you think is more sane, then implement middleware in thate.
Build the next great thing on top of WSGI, because in the end, the answer is either WSGI, something that's architecturally equivalent, or else each framework has to have its own compression, session, and other libraries. And no answer is going to save you from having to do a little bit of work to put things put together correctly.