[Web-SIG] WSGI Lite

PJ Eby pje at telecommunity.com
Fri Mar 22 20:02:00 CET 2013


[Please follow-up to web-sig, rather than emailing me privately.  Thanks.]

On Fri, Mar 22, 2013 at 6:52 AM, Simon Yarde <simonyarde at me.com> wrote:
> If I have two layers of middleware, can I trust the intermediate layer has
> not altered or wiped out any dotted-name keys in the environ prior to
> calling the layer below?

No; middleware isn't even required to pass the same environ object to
a nested app.  But most middleware will, and won't delete things in
it.


> I discovered your article on WSGI Lite as I was having similar ideas about
> binding for the purposes you describe; auth, session, cart etc. and keeping
> the app code minimal. I was aiming to find a way to allow objects
> initialised with an environ to interrupt execution at initialisation time
> and return a response. I felt something like this was needed to avoid doing
> this at the top of every app:
>
>     def app(input=Parse(XML, JSON),
> auth=Auth):
>        if not input:
>            return NotAcceptableResponse
>         if not auth:
>             return UnAuthorisedResponse
>
> I was playing around with a factory-method approach that would either return
> an instance or a 3-tuple response; the binding process would identify the
> result as an instance and add it to the calling args, or interrupt the  call
> and return it.

Raising an exception to be caught would probably be preferable.  It
might be that the Lite protocol should add a way to convert an
exception to a response, e.g. by looking for a
__wsgi_response__ attribute on it.  That way, you could raise anything
you wanted as a default response, and the error would convert to a
response at the WSGI 1/Lite boundary.

This would mostly be suitable for app-specific errors, but of course
you could put error-handling middleware anywhere in the stack below
the boundary, or formatting middleware above the boundary.

So, thus far, possible extensions to the Lite protocol would be:

* Exception to response conversion
* A standard for stripping custom HTTP headers

I don't have any idea as to when I might get around to these, but if
somebody wants to create a model patch or two, that'd be cool.  ;-)

The protocol of course is looking less and less "lite" with these
additions, but I suppose if one looks at "lite" as actually being a
collection of "microprotocols" it's not bad at all.  Everything in
Lite is essentially orthogonal right now (and would continue to be
with these additions), so it's nothing like the obscenity of
complexity and legacies that is WSGI's core.  ;-)


More information about the Web-SIG mailing list