Howdy!
There's one issue I've seen repeated a lot in working with WSGI1 and
that is the use of middleware to process incoming data, but not
outgoing, and vice-versa; middleware which filters the output in some
way, but cares not about the input.
Wrapping middleware around an application is simple and effective, but
costly in terms of stack allocation overhead; it also makes debugging a
bit more of a nightmare as the stack trace can be quite deep.
My updated draft PEP 444[1] includes a section describing Filters, both
ingress (input filtering) and egress (output filtering). The API is
trivially simple, optional (as filters can be easily adapted as
middleware if the host server doesn't support filters) and easy to
implement in a server. (The Marrow HTTP/1.1 server implements them as
two for loops.)
Basically an input filter accepts the environment dictionary and can
mutate it. Ingress filters take a single positional argument that is
the environ. The return value is ignored. (This is questionable; it
may sometimes be good to have ingress filters return responses. Not
sure about that, though.)
An egress filter accepts the status, headers, body tuple from the
applciation and returns a status, headers, and body tuple of its own
which then replaces the response. An example implementation is:
for filter_ in ingress_filters:
filter_(environ)
response = application(environ)
for filter_ in egress_filters:
response = filter_(*response)
I'd love to get some input on this. Questions, comments, criticisms,
or better ideas are welcome!
— Alice.
[1] https://github.com/GothAlice/wsgi2/blob/master/pep-0444.rst
_______________________________________________
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
