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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
