[Web-SIG] help with the implementation of a WSGI middleware
manlio_perillo at libero.it
Mon Jul 7 23:21:11 CEST 2008
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:
> 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:
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.
However my messages middleware does not "inject" an API into the WSGI
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:
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
More information about the Web-SIG