[Web-SIG] help with the implementation of a WSGI middleware
Phillip J. Eby
pje at telecommunity.com
Mon Jul 7 23:06:20 CEST 2008
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.
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.
More information about the Web-SIG