[Web-SIG] help with the implementation of a WSGI middleware

[Phillip J. Eby]

At 09:58 PM 7/7/2008 +0200, Manlio Perillo wrote:
>In this case the first solution is to use this middleware as a 
>decorator, instead of a full middleware.

This is the correct way to implement non-transparent middleware; 
i.e., so-called middleware which is in fact an application API.  See:

http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

for more about this.

Basically, if a piece of middleware has to be there for the 
application to run, it's not really "middleware"; it's a misnamed decorator.

In the original WSGI spec, I overestimated the usefulness of adding 
extension APIs to the environ... or more likely, I went along with 
some of Ian's overenthusiasm for the idea.  ;-)  Extension APIs in 
the environ just mean you have to write your code to handle the case 
where the API isn't there -- in which case you might as well have 
used a library.

Extension APIs really only make sense if they are true *server* 
features, not application features; otherwise, you are better off 
using a library rather than "middleware" per se.

Under WSGI 2.0, it's even easier since you don't need decorators to 
manipulate your response: you can just "return someapi(...)" where 
the "..." is whatever you were going to return directly.