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

[Manlio Perillo]

Phillip J. Eby ha scritto:
> 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.
> 

Right, this what I thought (and yes, I have read your article).

However as a "justification" I used the following argumentation:
Ok, the application does not "fully" work without the middleware, 
however it "mainly" works, and it's not a big problem is messages are 
not actually sent to the client.


Fortunately, in wsgix a "middleware" is very easy to use both in a full 
middleware stack and as a decorator (since all the state is maintained 
in the environ dictionary and there is no need for factory functions).

In Nginx you can do, in server config:

    wsgi_middleware  wsgix.contrib.messages;


However I want to document that this is not a "good" middleware.
"non-transparent middleware" is a good term, thanks.

> 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.
> 

Yes.
However my messages middleware does not "inject" an API into the WSGI 
environment.

The API uses the environ to store state; the middleware is only required 
to "activate" the cookies to actually send messages to the client.

So this is not a "bad" middleware, IMHO.


By the way, a middleware that is responsible for user authentication:
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/auth/http_middleware.py

is a good middleware?

To keep it simple, the middleware check if there is an authorization 
header and the credentials are correct.

If this is true, execute the WSGI application (setting 
environ['REMOTE_USER']), otherwise return a forbidden response.


> 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.
> 


return someapi() from inside the WSGI application?



Thanks   Manlio Perillo