Hans Then wrote: > Phillip, > >> -1 on this being middleware. If middleware wants to read the input, >> it should copy it to a temporary file or StringIO, not remove it. > >> The simple, standard way to do something like this would be to have a >> library routine like 'get_form_vars(environ)'. The routine would >> check for the form vars key, and if not present, then it would >> process the input and cache the information in the environment. It >> could even have an option to clone the input, in case the routine is >> being used from middleware. > > I think Ian's point is to standardise on a form key and on the interface of > the form object. Your point is valid that middleware should not > destructively read the wsgi.input variable. > > Many web applications will at some point call other web applications. It > seems positively wasteful to have to clone and parse wsgi.input over and > over again. It makes sense to do it once, in middleware, and then stuff it > in a standard place in the wsgi environ.
Ideally I'm not expecting middleware to do this parsing (unless there's some good reason for the middleware to want the information). I'm suggesting a way the parsing can be done in a lazy fashion, but that one consumer doesn't get exclusive access to it. I also see this as a kind of prerequisite for supporting multiple request objects over the WSGI environment, as each object is going to want access to wsgi.input. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ 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